Как сделать так, чтобы IT-продукт не прогорел? Часть 1

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

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

Последние три года я занимаюсь системным запуском и развитием IT-проектов. И потихонечку начинаю делиться накопленным опытом.

Живое общение я веду в своем телеграм-канале t.me/mpudalov_note

Собственно не менее 90% молодых бизнесов прогорают. Для того чтобы этого не случилось с вашим, необходимо сделать две вещи:

1. Вы должны тратить ВСЕ время и ВЕСЬ мозгоресурс на бизнес.

2. Вы должны тратить ВСЕ деньги на бизнес.

Эти пункты необходимы но, к сожалению, недостаточны. Поскольку Спутник вкладывает как собственные деньги, так и деньги инвесторов, и при этом не действует по принципу классического венчура (дадим деньги 100 стартапам, один выстрелит и все окупит) - мне пришлось за три года выработать определенный подход к управлению рисками. Коим я начну потихонечку делиться.

Для начала классифицируем риски по группам, поскольку с каждой группой надо работать отдельно:

• Технологические риски.

• Бизнесовые риски.

• Личностные риски.

Пройдемся по каждой группе.

Технологические риски

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

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

1. Не реализовать проект

2. Не смочь его сопровождать и поддерживать

Внимание! Специальная сноска для программистов: 

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

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

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

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

• Грамотная архитектура, включающая в себя подбор программно-аппаратных средств всех уровней (от языка разработки, до конкретных готовых решений).

• Команда, имеющая опыт работы с большей частью данной архитектуры.

• Лицо, способное проверить соответствие этой архитектуры потребностям бизнеса

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

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

Дело в том, что у программистов тоже есть своя “мода”. А еще им чаще всего класть с высокой колокольни на ваш бизнес, им главное развитие себя, как специалиста. Именно поэтому я периодически наблюдаю условные сайты-визитки написанные на Java. Я думаю, что периодически наблюдал бы даже бэкенд написанный на Assembler, если бы современное поколения JavaScripter’ов со SkillBox знало бы, что такое регистр.

Поэтому для архитектуры должны быть выставлены конкретные бизнес-требования. А именно:

1. Скорость реализации первой версии.

2. Средняя стоимость разработчика на рынке и их количество.

3. Скорость внедрения нового специалиста в команду.

4. Скорость внедрения изменений (желательно разобрать на примере конкретных кейсов).

Вот собственно и все. Тему можно развивать бесконечно, с радостью это сделаю на основе вопросов, если таковые будут.

И…. Если вы не поняли половину данной статьи, то у вас есть два варианта:

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

Либо НЕ ОТКРЫВАЙТЕ IT-СТАРТАП! Пожалуйста!

Какие внешние признаки для вашего будущего технического директора:

1. Не менее 10 лет стажа работы. До этого момента преодолеть модные тенденции и прочий мусор в голове разработчика почти не реально.

2. Работа на позиции руководителя, опыт в выборе архитектуры. Не ведитесь на громкие названия. Для вас важнее человек, который 10 лет отпахал в стартапе в роле Тимлида, пусть даже стартап не выстрелил, чем какой-нибудь третий слева задрот из условного Яндекса.

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

Поделитесь в комментариях вашим опытом запуска IT-проектов и как вам удалось или не удалось справиться с технологическими рисками.

Как-то так. Всем добра и много денег!

Мои предыдущие статьи вы можете посмотреть здесь

Самая популярная из них Сколько должен зарабатывать разработчик?