РИСКИ или О чем мы забываем на старте разработки продукта-сервиса. Часть 1.

Дорогие 71, сколько раз в жизни проекта у вас наступали те самые риски, которые были зафиксированы в паспорте проекта? А сколько раз наступало непредусмотренное "все пропало, мы все сгинем в пучине факапов"?

Мое предвзятое мнение - 9 из 10 рисков проекта невозможно предусмотреть, потому что на старте проекта мы забываем о нескольких важных вещах. Рассказать обо всем, конечно же, я не смогу (потому что половину забыла), но о некоторых моментах напомню. Вдруг вы именно сейчас запускаете проект и вам понадобится!?

1. Документация
Часто документация воспринимается как второстепенная задача, которая "подтянется по ходу дела". Но это большая ошибка выжившего. Почему? Всем понятно, что без ТЗ получится “что-нибудь”. Но не очень очевидно, что помимо ТЗ, на старте лучше обсудить: архитектуру проекта и программные и аппаратные компоненты; объектную модель; ролевую модель; кто будет писать инструкции администратора и пользователей; сценарии и программу тестирования; наверное, что-то еще… Потратьте время и обсудите с подрядчиком документацию - сбережете нервы.

РИСК: дополнительный бюджет/конфликтная ситуация с исполнителем/неверная интерпретация задачи/срыв сроков/сложность в масштабировании и поддержке кода.

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

РИСК: продукт не попадет в PMF/проблемы с монетизацией.

3. Custdev часть.
Customer Development часто игнорируется или проводится формально (да-да, продуктовый подход бывает не очень продуктовым на деле). Однако, это критически важный этап. Правильные вопросы позволят выявить те сценарии использования, которые не покажет аналитика, а также объяснить причины аномалий в данных.

РИСК: продукт не попадет в PMF/проблемы с монетизацией/высокие затраты на дальнейшую доработку.

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

РИСК: ошибки интеграции

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

Продолжение следует… ()

#ProjectManagement #ITLeadership #Startup #Tech #Innovation #Productivity #Leadership #Success #Software #Development