Как сделать так, чтобы ИТ-продукт не прогорел? Часть 1
Итак, начинаю серию постов про работу с рисками в проектах.
Как говорится — смело сыпьте обратную связь в комментариях, для меня это важно.
Меня зовут Максим Пудалов, я суровый сибирский программист, предприниматель, инвестор. Прошел путь от разработчика до генерального директора.
Последние три года я занимаюсь системным запуском и развитием IT-проектов. И потихонечку начинаю делиться накопленным опытом.
Живое общение я веду в своем телеграм-канале t.me/mpudalov_note
Собственно не менее 90% молодых бизнесов прогорают. Для того чтобы этого не случилось с вашим, необходимо сделать две вещи:
1. Вы должны тратить ВСЕ время и ВЕСЬ мозгоресурс на бизнес.
2. Вы должны тратить ВСЕ деньги на бизнес.
Эти пункты необходимы но, к сожалению, недостаточны. Поскольку Спутник вкладывает как собственные деньги, так и деньги инвесторов, и при этом не действует по принципу классического венчура (дадим деньги 100 стартапам, один выстрелит и все окупит) - мне пришлось за три года выработать определенный подход к управлению рисками. Коим я начну потихонечку делиться.
Для начала классифицируем риски по группам, поскольку с каждой группой надо работать отдельно:
- Технологические риски.
- Бизнесовые риски.
- Личностные риски.
Пройдемся по каждой группе.
Технологические риски
Обожаю людей которые говорят - мой бизнес на фрилансерах, поэтому я экономлю кучу денег, ведь я плачу им за результат. А еще я их кидаю через раз, либо грубо либо по-хитрому. Об этом люди обычно не говорят, но читается между строк. При такой организации работ купировать технологические риски невозможно, их можно только переложить на клиента. Такой способ организации труда в действующем бизнесе, встречал только у тех кто делает проекты в стол, по сути обманывая клиента.
Если мы говорим о продуктовой разработке, то у нас есть два ключевых технологических риска:
1. Не реализовать проект
2. Не смочь его сопровождать и поддерживать
Именно потому, что люди годами работающие в заказной разработке, плохо это понимают, такие команды не подходят для реализации продукта. Для них результат - это "сделать по ТЗ" и "пропихнуть клиенту". И если в целом для разработчика такой способ мышления приемлем, то когда так мыслит аналитик....
Но я отвлекся. Важно понимать, что это два главных риска. Умные товарищи наверняка могут написать диссертацию, декомпозируя эти риски, но я этого делать не буду, потому что я не умный - я предприимчивый. Поэтому я перечислю, что должно быть для того, чтобы риск купировать:
Грамотная архитектура, включающая в себя подбор программно-аппаратных средств всех уровней (от языка разработки, до конкретных готовых решений).
Команда, имеющая опыт работы с большей частью данной архитектуры.
- Лицо, способное проверить соответствие этой архитектуры потребностям бизнеса
Основная дилемма при разработке архитектуры, которую нужно решить - это дилемма между простотой поддержки и скоростью разработки.
На первый взгляд, чем более основателен подход к разработке первой версии, тем проще ее потом поддерживать. Но это не всегда так.
Дело в том, что у программистов тоже есть своя “мода”. А еще им чаще всего класть с высокой колокольни на ваш бизнес, им главное развитие себя, как специалиста. Именно поэтому я периодически наблюдаю условные сайты-визитки написанные на Java. Я думаю, что периодически наблюдал бы даже бэкенд написанный на Assembler, если бы современное поколения JavaScripter’ов со SkillBox знало бы, что такое регистр.
Поэтому для архитектуры должны быть выставлены конкретные бизнес-требования. А именно:
1. Скорость реализации первой версии.
2. Средняя стоимость разработчика на рынке и их количество.
3. Скорость внедрения нового специалиста в команду.
4. Скорость внедрения изменений (желательно разобрать на примере конкретных кейсов).
Вот собственно и все. Тему можно развивать бесконечно, с радостью это сделаю на основе вопросов, если таковые будут.
И…. Если вы не поняли половину данной статьи, то у вас есть два варианта:
Либо найдите партнера, который поймет эту часть статьи, дайте ему роль технического директора и долю в бизнесе.
Либо НЕ ОТКРЫВАЙТЕ IT-СТАРТАП! Пожалуйста!
Какие внешние признаки для вашего будущего технического директора:
- Не менее 10 лет стажа работы. До этого момента преодолеть модные тенденции и прочий мусор в голове разработчика почти не реально.
- Работа на позиции руководителя, опыт в выборе архитектуры. Не ведитесь на громкие названия. Для вас важнее человек, который 10 лет отпахал в стартапе в роле Тимлида, пусть даже стартап не выстрелил, чем какой-нибудь третий слева задрот из условного Яндекса.
- Вы должны понимать, что сможете установить сильный личный, доверительный контакт с этим человеком. Несмотря на все вышеперечисленное, проблемы будут. И вам придется их решать вместе.
Поделитесь в комментариях вашим опытом запуска IT-проектов и как вам удалось или не удалось справиться с технологическими рисками.
Как-то так. Всем добра и много денег!
Мои предыдущие статьи вы можете посмотреть здесь
Самая популярная из них Сколько должен зарабатывать разработчик?
Приветствую, Максим.
1) Кажется на VC заходят объемные статьи, эта больше похожа на пост в ТГ. Лично мне было интересно, но мало.
2) Вариант найти CTO описанного вами кажется слабореализуем, либо они сидят на высокой зп и все свободное время тратят на семью/хобби и доп проект им нафиг не нужен, либо они только вышли из найма и разговоры о работе вызывают аллергию. ИМХО.
Комментарий удален автором поста
Здравствуйте, Илья!
1) Спасибо за обратную связь, постараюсь учесть! Из-за общей нагрузки выдаю материал порциями, поэтому такой объем :(
2) Из моей практики наиболее удачный пример - тимлид, которому важно долевое участие в проекте, чтобы мочь реализовывать свои амбиции. Если проект это позволяет, то есть реальные шансы привлечь такого в команду.