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