День 2307. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 52. Не спрашивайте: «Что это даст мне?» Спрашивайте: «Что это даст нам?»
Когда людям предлагают использовать новый подход к разработке, следовать другой процедуре или взяться за неожиданное задание, они инстинктивно задаются вопросом: «Что это даст мне?» Это естественная реакция, но не совсем правильный вопрос. Правильный вопрос: «Что это даст нам?»
«Нам» тут может относиться к остальным членам команды, IT-отделу, компании или даже индустрии, только не к отдельному человеку. Инициативы по внедрению изменений должны учитывать коллективные результаты работы, а не только влияние на продуктивность, эффективность или уровень комфорта каждого человека.
Может показаться, что просьба к занятому коллеге, например проверить вашу работу, не принесёт ему выгоды. Однако все вместе такие усилия позволят команде сэкономить больше времени, и тем самым внести чистый положительный вклад в проект. Ревью кода может занять два-три часа времени каждого участника. Эти часы рецензенты не смогут потратить на выполнение своих обязанностей. Но проверка выявит дефекты, а чем раньше они обнаруживаются, тем дешевле их исправление.
Выгода для команды
Предположим, Ари (бизнес-аналитик) написала несколько страниц требований и попросила троих коллег просмотреть их. Каждый из четверых потратил по часу на изучение материала перед встречей команды, которая тоже длилась час:
затраты на подготовку = 1 час/рецензент × 4 рецензента = 4 часа;
затраты на встречу = 1 час/рецензент × 4 рецензента = 4 часа;
общие затраты на рецензирование = 4 часа + 4 часа = 8 часов
Предположим, в процессе рецензирования обнаружены 24 дефекта разной степени серьёзности и на исправление каждого у Ари ушло в среднем 5 минут:
фактические затраты на доработку = 24 дефекта × 0,0833 часа/дефект = 2 часа
Теперь представьте, что Ари не запросила рецензирование. Дефекты останутся в наборе требований и будут обнаружены позже, при разработке. Ари всё так же придётся исправить их, а другим членам команды — переделывать проектное решение, код, тесты и документацию после исправления дефектов. На все эти работы легко может понадобиться в десять раз больше времени. Стоимость переделки может возрасти ещё, если дефекты попадут в конечный продукт:
потенциальные затраты на доработку = 24 дефекта × 0,833 часа/дефект = 20 часов
То есть это гипотетическое рецензирование требований предотвратило потенциальные затраты 18 часов на доработку на последних этапах реализации проекта. Поэтому минимальная окупаемость затрат на рецензирование составляет 225% (18 часов сэкономленного времени ÷ 8 часов на рецензирование). Многие крупные компании оценивают рентабельность вложений в раннее рецензирование как десятикратную. У вас могут получиться другие цифры, но лишь немногие методы разработки ПО могут десятикратно окупить вложения.
Вносите свой вклад в общее дело
В следующий раз, когда коллега или руководитель попросит вас сделать в проекте что-то, что не принесёт вам личной выгоды, думайте не только о своих интересах. Сотрудники несут ответственность за соблюдение установленных правил и приёмов разработки. Справедливо спросить: «Что нам это даст, если я это сделаю?» На просителе лежит бремя объяснения того, какую пользу всей команде принесет ваш вклад. А вы старайтесь внести свой вклад в общий успех команды.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
>>Click here to continue<<