9 способов снизить проектные риски и сократить затраты. Бонус всем дочитавшим!

Как связаны проектные риски и тех. документация?

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

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

На вопрос “Почему?” у меня есть несколько очевидных ответов.

Для заказчика не очевидно, почему он должен оплачивать тексты, которые, зачастую стоят 10-20% от бюджета будущего моб. приложения. Для студии мобильной разработки иногда непонятно, как продать идею необходимости ТЗ для успешности будущего продукта и его конечная ценность для участников.

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

Участники процесса разработки

Рассмотрим типовые отношения по разработке нового продукта в срезе участников процесса:

Со стороны заказчика проектный менеджер и/или владелец стартапа (носитель идеи)

Со стороны исполнителя минимальный набор:

• sales он же проектный менеджер. В зависимости он размера компании эта роль может совмещать в себе аналитика
• UX / UI дизайнер
• мобильный разработчик
• серверный разработчик
• тестировщик

ТОП 9 рисков на проекте - версия автора

Посмотрим на взаимоотношения критически - с точки зрения рисков (если что то упустил - прошу добавить в комментариях):

1. Инвестиции в ненужный продукт.
2. Разное понимание целей и задач проекта.
3. Несоблюдение сроков реализации проекта.
4. Превышен бюджет разработки.
5. Изменение концепции продукта.
6. Смена команды разработки или ключевых ее участников.
7. Смена команды заказчика.
8. Проблема тестирования продукта.
9. Проблема приемки продукта заказчиком

Как же минимизировать эти риски при помощи грамотно составленного ТЗ?

Начнем по - порядку:

Инвестиции в ненужный продукт.

Очевидно, что ТЗ, само по себе, не может исключить риск разработки провального стартапа, но может его существенно минимизировать этот риск за счет того, что технологически сложный IT продукт, опираясь на ТЗ, можно разбить на версии и сделать что-то важное за меньшие деньги. Как это примерно происходит:

• описать все возможности будущего продукта, оценить из сточки зрения ценности / сложности / ориентации на бизнес-цели
• вместе с заказчиком выделить наиболее значимые функции продукта, создать product roadmap
• продумать пользовательский опыт внутри системы
• выйти на рынок с MVP (минимально - жизнеспособным продуктом)
• по результатам запуска принять решение о разработке остальных модулей системы

Разное понимание целей и задач проекта.

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

Разберем на примере:

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

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

Требование в ТЗ - масштабирование

Варианты:

а) сделать простую архитектуру за небольшой бюджет

б) инвестировать в масштабируемую архитектуру, которая, с большой вероятностью, никогда не пригодится.

Какой вариант верный?

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

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

Несоблюдение сроков реализации проекта.

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

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

1. получить первичные оценки
2. синхронизировать задачи между серверной и мобильной разработкой (чтобы исключить возможные простои в работе)
3. составить план разработки и тестирования
4. определить критерии сдачи - приемки проекта

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

Даже такая нехитрая формула позволит сформулировать наиболее приближенные к реальности сроки.

Превышен бюджет разработки.

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

Пример:

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

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

Интеграция инструмента, например, Google Analytics требует от исполнителя дополнительных ресурсов (если нужно не просто поставить счетчик, а работать с целями).

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

Изменение концепции продукта

Ситуация встречается очень и очень часто, в процессе согласования договора, переписки и прочей предпроектной суеты очень просто может оказаться так, что мобильное приложение заказа такси будет еще и социальной сетью, это может выясниться на этапе, когда договор подписан и стоимость зафиксирована. Без детального ТЗ исполнитель оказывается в неприятной ситуации сделать большой блок работы за свой счет (конечно же боясь потерять вкусного клиента).

Смена команды разработки или ключевых ее участников

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

Смена команды заказчика

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

Согласованное ТЗ тут весомый аргумент для конструктивного диалога, например сделали 60% от заявленного функционала, первое DEMO системы будет готово к показу тогда-то и будет включать такие-то возможности.

Проблема тестирования продукта

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

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

Проблема приемки продукта заказчиком

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

Выводы:

Выводы, если вы исполнитель - не пишите ТЗ если:

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

Выводы, если вы заказчик - вам не нужно ТЗ, если:

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

Скачать шаблон технического задания (ТЗ) бесплатно, без регистрации и SMS

Спасибо.