Создание команды, которая будет производить программное обеспечение хорошего качества: проблема потери информации

Как сказал Гарольд Ф. Додж:

Вы не можете проверить качество продукта.

Он имел в виду, что система должна быть спроектирована так, чтобы производить качественный продукт.

Эта статья посвящена дизайну команды: принципам построения команды, которые позволят ей производить качественный продукт.

Мы знаем, что такое «продукт»: информационная система, позволяющая клиенту что-то сделать.

А знаете ли вы, что такое «команда&; аспекты проектирования процесса, которые влияют на качество продукта, создаваемого вашей командой?

Давайте разберемся и начнем с определений.

Что такое качество?

Качество определяется двумя стандартами:

Общий (для продукции) — ISO 9000:

степень качества, в которой набор присущих характеристик соответствует требованиям.

И тот, который говорит конкретно о качестве программного обеспечения — ISO 25000:

качество программного обеспечения — способность программного продукта удовлетворять заявленные и подразумеваемые потребности при использовании в определенных условиях.

Оба говорят о «соответствии» между тем, что хотел клиент, и тем, что есть (произведено).

Мы хотим произвести именно то, что нужно или хочется, чтобы соответствие было «максимальным», т.е. качество было на самом высоком уровне.

При создании команды может возникнуть несколько проблем, связанных с качеством.

Потеря информации при преобразовании

Идея или желание никогда не могут быть выражены полностью: преобразование идеи в язык приводит к потере информации. Считайте, что это похоже на цифровое -> аналоговое преобразование.

Затем идея (преобразованная в язык) в процессе восприятия будет иметь еще большую потерю информации; считайте это аналогом -&gt- цифровой трансформации.

Причина потери проста:

  • сам язык неоднозначен
  • язык может предоставить нам только символическое представление значения
  • символ воспринимается по-разному, поэтому смысл не постоянен, а привязан к времени, контексту и индивидуальности.

Приведенный выше рисунок иллюстрирует неоднозначность символической системы, вызванную различными перспективами (точками зрения) собеседников.

Существует две области науки, изучающие этот специфический набор проблем: Семиотика и Семантика.

Очень просто говоря, «шахматы» могут описывать «шахматную доску» или «игру в шахматы», «зеленый» нельзя объяснить слепому, «соленый» может восприниматься по-разному не только разными людьми, но и одним и тем же человеком в разное время.

Эксперимент с разбитым телефоном иллюстрирует, как увеличивается потеря информации: чем больше звеньев в цепи потока информации, тем больше раз информация подвергается трансформации восприятия/вербализации, тем больше потеря информации.

1. Чем меньше звеньев в цепи обработки информации, тем выше ее качество.

Этот принцип имеет четыре следствия:

  • команды должны сидеть ближе к клиенту
  • команды должны быть как можно меньше
  • команды должны быть кросс-функциональными (никаких силосов)
  • знания членов команды должны пересекаться

1.1 Команда должна сидеть ближе к клиенту

Клиент является источником информации, чем ближе команда сидит к клиенту, тем выше качество: меньше потерь информации. В идеале представитель клиента должен сидеть прямо с командой.

Кроме того, если представитель клиента сидит вместе с командой, команда может чаще показывать промежуточные результаты и получать больше обратной связи.

Это очень важно просто потому, что клиент может даже не до конца понимать потребность, или первый способ реализации его желания может не удовлетворить клиента. Чем короче цикл обратной связи, тем меньше ненужной работы.

1.2 Команда должна быть как можно меньше

Если всего один инженер помогает клиенту достичь того, что ему нужно, потеря информации минимальна — в цепочке всего два звена: клиент -> инженер.

Если информация следует по потоку клиент->бизнес-аналитик->архитектор->системный аналитик->инженер->QA, то существует шесть звеньев, шесть раз происходит преобразование, информация теряется значительно.

Есть только два способа преодолеть присущую потерю информации: указать все более подробно или уменьшить количество звеньев в цепи.

Более детальная спецификация требует времени, которое имеет огромное значение (мир меняется слишком быстро). Все движение Agile началось с цели предоставить клиентам то, что они хотят, но быстрее и лучше.

Исследования доказывают, что чем меньше команда, тем выше качество.

Следует также отметить, что чем больше разработчиков в команде, тем выше вероятность «размывания ответственности», когда люди видят менее очевидные результаты своих усилий.

Это может привести к тому, что люди потеряют мотивацию или будут относиться к работе по принципу «это может сделать кто-то другой».

Менеджеры должны спросить себя: какой минимум людей необходим для производства того, что хочет клиент?

Можно ли произвести программный продукт, имея всего 1 сотрудника, непосредственно общающегося с клиентом (или его представителем)? Если нет, то можно ли обойтись двумя? Или 3?

1.3 Команда должна быть кросс-функциональной (без силосов)

В социальной психологии есть множество исследований концепции, называемой внутригрупповым фаворитизмом:

тенденция реагировать более позитивно на людей из наших ингрупп, чем на людей из других групп.

Описана парадигма минимальной группы:

Эксперименты с использованием этого подхода показали, что даже произвольные различия между группами, такие как предпочтение определенных картин или цвет рубашек, могут вызвать тенденцию отдавать предпочтение своей собственной группе за счет других, даже если это означает жертвовать внутригрупповой выгодой.

По сути, люди легко формируют группы и тут же начинают предвзято относиться к членам аутгруппы или даже дискриминировать их.

Причина такого разделения, как показывают исследования, может быть столь же незначительной, как цвет рубашки:

Поскольку наши предки жили в небольших социальных группах, которые часто конфликтовали с другими группами, для них было эволюционно функциональным рассматривать членов других групп как непохожих и потенциально опасных. Дифференциация между «нами» и «ими», вероятно, помогала нам оставаться в безопасности и быть свободными от болезней, и в результате человеческий мозг стал очень эффективным в проведении таких различий.

Зная эту особую социальную динамику, которую люди имеют в группах, кажется очевидным, что нет места для разделения команд на основе специализации.

Именно поэтому была создана концепция междисциплинарной (или межфункциональной) команды.

Межфункциональная команда включает в себя несколько человек всех специальностей, необходимых для предоставления ценности клиенту.

Не разделяйте членов команды, работающих над продуктом, на подкоманды по признаку специализации, и вы не получите негативной социальной динамики межгрупповой дискриминации или предрассудков.

1.4 Знания членов команды должны пересекаться

Если ваша команда состоит из людей, специализирующихся только в очень узкой области знаний, каждый акт коммуникации потребует дополнительных усилий по «наведению мостов» для преодоления потери информации.

Вообще говоря, если ваш iOS-разработчик разбирается в разработке бэкенда, их общение будет проще.

Это одна из причин появления таких понятий, как T-образная форма, Devops и TestOps.

Подведем итоги принципа «меньше связей»:

  • получить клиента (или его представителя) прямо в команде
  • определите, какое минимальное количество людей с какими специализациями необходимо вашей команде
  • не разделяйте специалистов на подкоманды, пусть они будут сосредоточены на выполнении того, что нужно клиенту
  • убедитесь, что их знания пересекаются.

Это уменьшит потерю информации и, следовательно, сократит количество «отходов»:

Отходы — это любая деятельность, которая не приносит никакой пользы клиенту или пользователю. Это зависит от продукта, который вы создаете.

В следующей статье я расскажу о концепции потери качества из-за особенностей проектирования системы.

Оцените статью
devanswers.ru
Добавить комментарий