5 must have в создании качественного ПО: инструментарий, «инциденты», общение с клиентом и прочее

1. Сбор требований и ожиданий заказчика

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

Хочешь быстро стартовать в IT? Выбирай направление для обучения в каталоге курсов программирования.

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

Если мы говорим о подборе команды, важно уточнить у клиента:

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

 

С какими трудностями мы сталкивались?

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

---

---

• На одном из проектов только на этапе демонстрации клиенту мы выяснили, что значительная доля пользователей прежней версии приложения использовала Windows Phone, — в требованиях это не было зафиксировано. Команде срочно пришлось отлаживать продукт на этом устройстве, потратив немало времени.

 

Что делать?

1. Обязательно работать с ожиданиями клиентов и задавать важные вопросы не только по итоговому результату, но и по взаимодействию: договариваться по содержанию и форме отчетности, периодичности информирования и подготовке статусов. Таким образом, работа команды будет прозрачной и соответствующей ожиданиям заказчика.
2. Фиксировать все явные и неявные требования к продукту с помощью чек-листов. Например, мы заранее обговариваем с клиентом нефункциональные требования, критерии приемки, формат документации, дополнительные условия и оформляем это как договоренность.
3. Если какие-либо требования озвучены на митинге, записываем их со своей стороны и напоминаем заказчику, чтобы включить в бэклог, обновить текущие требования или отказаться от их внедрения. По завершению созвонов мы всегда готовим резюме, прописываем в задачах все обновления и договоренности, а самые важные подтверждаем в письмах.
4. Во время сбора требований аналитики и команда должны задавать вопросы, которые будут касаться разных нефункциональных особенностей.

---

Читайте по теме: Красный флаг: когда ИТ-проект может обернуться провалом

---

Например, по оценке кроссбраузерности и совместимости:

1. Смогу ли я зайти в приложение с телефона?
2. Что будет, если повернуть экран телефона?

По оценке нагрузки и производительности:

• Сколько пользователей одновременно будут пользоваться этой функцией?
• Какой пик нагрузки у приложения, выдержит ли оно?

Если ранее эти вопросы не были подняты на этапе аналитики, команда тестирования не должна их упустить. В идеале нужно добавить этап тестирования требований и сформировать чек-листы, по которым можно будет пройтись в самом начале работы над проектом.

---

Читайте также: Работа со стейкхолдерами: как владельцу продукта управлять ожиданиями сторон

---

 

2. Внимание к бюджету и дополнительным расходам

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

• на управление,
• коммуникации,
• создание поддерживаемого кода и его стабилизацию (митинги команд, обсуждения, code review, регресс и фикс багов). 

 

С какими трудностями мы сталкивались?

При разработке продукта у клиента может возникнуть вопрос, зачем платить за баги, митинги — не лучше бы обойтись без них? Но полностью исключить их невозможно, какой бы профессиональной ни была команда.

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

---

Читайте по теме: ТЗ на разработку. Как его написать, если вы не айтишник?

---

 

Исключение

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

 

Что делать?

• С самого начала открыто показывать возможные риски и связанные с ними расходы, объяснять их заказчику.
• Аргументировать необходимость учета времени на управление, коммуникации, создание поддерживаемого кода и его стабилизацию. 
• Объяснять, почему возникают баги, что такое регрессионные баги. Донести до всех заинтересованных сторон, что нельзя полностью исключить баги при разработке.

 

3. Правильный выбор инструментов

Все знают, что для ведения проекта должны быть:

• таск-трекер

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

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

• roadmap

---

---

• понятный workflow

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

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

Еще нужны минимальные метрики, которые, к сожалению, не каждый применяет эффективно.

 

С какими трудностями мы сталкивались?

1. На одном из небольших внутренних проектов ПМ не отслеживал сроки и фактически затраченные часы на задачи. В результате команда не смогла оперативно скорректировать бэклог, решить возникшие проблемы и уложиться в срок.
2. В самом начале работы мы использовали типовой workflow. По мере развития одного из проектов и увеличения объема задач мы заметили, что производительность команды стала «проседать».

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

 

Что делать?

• Независимо от размера проекта следить за сроками и снимать основные метрики.  Метрики, которые помогают в работе: план-факт, Burndown, процент возврата, процент Bug Fix.
• Внедрить workflow, который будет понятен всем членам команды. Если необходима более сложная схема, предусмотреть методы внедрения и выполнения правил.
• По системе менеджмента качества мы используем инциденты — разбор любых отклонений от плана на проекте. В каждом случае выявляются причины возникновения проблемы и разрабатываются мероприятия, которые позволяют изменить подход к работе.

Например, в первой ситуации выше мы приняли решение разработать стандарт ведения задач в таск-трекере и минимальный набор метрик. Если происходит аномальная ситуация (выход из сроков, оценки бюджета), аккаунт-менеджер или ПМ сообщает об этом и корректирует ведение проекта.

 

4. Четкость и понятность процессов

Качество ИТ-продукта зависит от многих выполненных шагов:

• все начинается с четкого выявления запроса клиента,
• поиска подходящих специалистов,
• аналитики,
• прорисовки и согласования архитектуры проекта.

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

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

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

 

С какими трудностями мы сталкивались?

С одним клиентом мы разрабатывали MVP.

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

При этом документация проекта не поддерживалась в актуальном состоянии. Архитектура и стиль написания кода были применимы для небольшого MVP-проекта, который было сложно масштабировать.

---

Читайте по теме: Проектная документация: какие нюансы учесть при разработке

---

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

 

Что делать?

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

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

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

 

5. Промежуточные результаты

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

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

Это позволяет:

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

 

С какими трудностями мы сталкивались?

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

 

Что делать?

Учитывать и планировать демонстрации заинтересованным сторонам, включать даты его проведения в roadmap проекта при наличии.

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

 

Резюме

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

• На старте задавать важные вопросы по ожиданиям всех заинтересованных сторон, проговаривать все явные и неявные требования к продукту.
• Фиксировать все требования, ожидания, а также изменения, озвученные на митингах в процессе разработки.
• Согласовывать на старте набор документов, артефактов на выходе. Определять минимальный уровень документации, которая должна быть актуальной даже в самом простом и очевидном проекте. 
• Объяснять важность и необходимость закладывать время на митинги, багофикс, код ревью и регресс. 
• Внедрять понятный команде workflow, которого будет легко придерживаться. Независимо от размера проекта следить за сроками и основными метриками.
• Учитывать и планировать демонстрации продукта всем заинтересованным сторонам.
• В случае возникновения проблем изучать каждый случай индивидуально и разрабатывать мероприятия, которые изменят подход к работе на проекте и в похожих ситуациях.

Надеемся, наш опыт поможет сделать ваши продукты лучше, а процесс разработки еще более эффективным.

 

Фото на обложке: Shutterstock / Foxy burrow