Качество vs скорость разработки — как найти баланс?

Вчера я участвовал в панельной дискуссии с таким названием на митапе Альфа Банка “Mobile Talks Онлайн”. Ниже я приложил видео с этого митапа, но для тех, кто предпочитает читать, я решил написать статью со своими мыслями на эту тему.

Запись митапа

В процессе общения мы затронули следующие темы:

  1. Как возникает противоречие между задачами бизнеса делать быстрее и желаниями разработчика делать качественно?
  2. Действительно ли качество и продуктивность — противоречия?
  3. Миражи высоких технологий. Каков процент действительно “интересных задач” по сравнению с ежедневно-рутинными, когда мы пользуемся результатами работы других людей/команд.
  4. Причины стагнации разработчиков: недостаток компетенции, нехватка уверенности, неопределенность целей, отсутствие интеграции с командой. Что делать и как решать?
  5. Текучка кадров. Как процесс повышения производительности влияет на выгорание сотрудников и мотивирует их искать удовлетворение от работы в другом месте.
  6. Как сделать перемены возможными?

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

Рис.1 “Сравнение взглядов product manager и software engineer”

Все начинается с требований, где product manager сфокусирован на функциональных возможностях продукта. НЕфункциональные требования для него часто то, что он НЕ рассматривает как свою зону ответственности и интереса. В то же самое время software engineer, познакомившись с функциональными требованиями, дальше погружается в царство нефункциональных требований, которые надо реализовать, чтобы все было хорошо:)

Интересно, что product manager время вывода на рынок является конкурентным преимуществом, поэтому для него чем раньше, тем лучше. Для инженера же время является естественным ограничением, которое в купе с другими ограничениями (функциональность и ограниченный размер команды), приводит к тому, что страдает качество. Про это подробнее я уже рассказывал во введении в управление проектами. Пожалуй самой интересной иллюстрацией для нас будет картинка треугольника ограничений.

Рис.2 “Проектный треугольник ограничений”

Эмпирическое правило при выборе в какие ограничения укладываться при выполнении проектов звучит так “ Выберите любые два из трех:)” В итоге, если ограничены стоимость и сроки, то начинает утекать функциональность и если product manager настаивает на определенном количестве фич, то страдает качество.

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

Интересно, что менеджер часто воспринимает доработки в продукт как требующие аддитивных усилий, но обычно сильно удивляется оценке сложности фичи, которую дает техническая команда, которая в разы отличается от его предположений. Все дело в том, что аддитивность действительно работает, если мы не запускали проект и не брали на себя избыточный технический долг, а также feature укладывается в запланированную логику развития системы. Если это не так, то системе иногда требуется фазовый переход для реализации запрошенного функционала. Иногда это приводит к проекту перехода от системы версии 1.X на версию 2.0

В общем, если закрыть product manager и software engineer работают в тесной связке, слушают друг друга и главное слышат, то такого разрыва в понимании можно избежать. В этом случае противоречия в долгой перспективе не будет и продакт будет понимать, что кратковременный буст производительности в количестве фич сменится дальнейшей засухой, так как придет время отдавать долги, точнее техдолги, которую я иногда называют технической ипотекой. Главное, чтобы не стало слишком поздно и не пришлось признавать себя техническим банкротом:)

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

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

Замечу, что важно использовать правильный нейминг (атрибуты качества) и строить риторику вокруг качества реализации фич, которое можно объяснить заказчику.

Это интересный вопрос и я предлагаю разобрать его по частям.

Во-первых, понятие “интересных задач” напрямую зависит от человека: его склонностей, опыта, технического уровня и так далее. Например, сейчас многие проекты кажутся мне простыми и не слишком интересными, чтобы самому заниматься ими. Причина в том, что я уже не раз делал что-то похожее еще когда был практикующим разработчиком и руководил небольшой командой. Сейчас я в таких проектах выступаю куратором и даю набраться опыта ребятам, для которых такие проекты являются интересными в силу своей новизны и вызова.

Во-вторых, даже если сейчас вы работаете над “интересными” вам задачами, то часть времени будет уходить на операционку: фикс багов, помощь и консультирование коллег, стандартные ритуалы типа дейли, планирования, ретро … И вот тут важно, чтобы эта операционка не стала занимать 100% времени

В-третьих, все течет, все меняется — те задачи, что еще вчера были интересными, сегодня становятся обычными, а завтра — уже рутиной. Поэтому для поддержания градуса интересности важно иметь горизонты для роста, например, это может быть:

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

Причин стагнации разработчиков вагон и маленькая тележка. По-факту, нужно разбираться с этим надо учитывая весь жизненный цикл разработчика и начать стоит с найма.

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

Онбординг может выглядеть по разному в разных компаниях или даже в разных подразделениях одной компании. Но в любом случае основная цель в том, чтобы помочь новичку адаптироваться, рассказав общепринятые правила и давая оперативную обратную связь во время погружения в новую для человека среду. После адаптации сотрудник заканчивает испытательный срок и важно помочь составить ему индивидуальный план развития (ИПР), укладывающийся в планы команды и бизнеса. Этот ИПР позволит сотруднику расти в вашей команде целенаправленно, повышать свой уровень знаний и навыков. Как результат сотрудник сможет наносить больше пользы и расти по карьерной лестнице. Если все сделано правильно, то сотрудники будут с вами долго и будут расти по уровням: junior -> middle -> senior -> … Кстати, количество выросших у вас ребят показывает насколько вы хороши как лидер команды.

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

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

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

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

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

  1. Запись круглого стола “Качество vs скорость разработки
  2. Моя статья “Про управление проектами
  3. Моя статья “Платформенные команды — что это такое и зачем они нужны
  4. Запись круглого стола “Платформенные команды: польза или вред
  5. Запись моего выступления “Как мы нанимаем и мотивируем сотрудников

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.