|
|
@@ -0,0 +1,47 @@
|
|
|
+# Как сделать так, чтобы IT-продукт не прогорел?
|
|
|
+Собственно не менее 90% молодых бизнесов прогорают. Для того чтобы этого не случилось с вашим, необходимо сделать две вещи:
|
|
|
+- Вы должны тратить ВСЕ время и ВЕСЬ мозгоресурс на бизнес.
|
|
|
+- Вы должны тратить ВСЕ деньги на бизнес.
|
|
|
+Эти пункты необходимы но, к сожалению, недостаточны.
|
|
|
+
|
|
|
+
|
|
|
+Для начала классифицируем риски по группам, поскольку с каждой группой надо работать отдельно:
|
|
|
+
|
|
|
+- Технологические риски.
|
|
|
+- Бизнесовые риски.
|
|
|
+- Личностные риски.
|
|
|
+
|
|
|
+Пройдемся по каждой группе.
|
|
|
+
|
|
|
+# Технологические риски
|
|
|
+
|
|
|
+Если мы говорим о продуктовой разработке, то у нас есть два ключевых технологических риска:
|
|
|
+
|
|
|
+- Не реализовать проект
|
|
|
+- Не смочь его сопровождать и поддерживать
|
|
|
+
|
|
|
+Важно понимать, что это два главных риска. Что должно быть для того, чтобы риск купировать:
|
|
|
+- Грамотная архитектура, включающая в себя подбор программно-аппаратных средств всех уровней (от языка разработки, до конкретных готовых решений).
|
|
|
+- Команда, имеющая опыт работы с большей частью данной архитектуры.
|
|
|
+- Лицо, способное проверить соответствие этой архитектуры потребностям бизнеса
|
|
|
+
|
|
|
+# Требования
|
|
|
+Основная дилемма при разработке архитектуры, которую нужно решить - это дилемма между простотой поддержки и скоростью разработки.
|
|
|
+На первый взгляд, чем более основателен подход к разработке первой версии, тем проще ее потом поддерживать. Но это не всегда так.
|
|
|
+
|
|
|
+Поэтому для архитектуры должны быть выставлены конкретные бизнес-требования. А именно:
|
|
|
+- Скорость реализации первой версии.
|
|
|
+- Средняя стоимость разработчика на рынке и их количество.
|
|
|
+- Скорость внедрения нового специалиста в команду.
|
|
|
+- Скорость внедрения изменений (желательно разобрать на примере конкретных кейсов).
|
|
|
+
|
|
|
+Какие внешние признаки для вашего будущего технического директора:
|
|
|
+
|
|
|
+- Не менее 10 лет стажа работы. До этого момента преодолеть модные тенденции и прочий мусор в голове разработчика почти не реально.
|
|
|
+- Работа на позиции руководителя, опыт в выборе архитектуры. Не ведитесь на громкие названия. Для вас важнее человек, который 10 лет отпахал в стартапе в роле Тимлида, пусть даже стартап не выстрелил, чем какой-нибудь третий слева задрот из условного Яндекса.
|
|
|
+- Вы должны понимать, что сможете установить сильный личный, доверительный контакт с этим человеком. Несмотря на все вышеперечисленное, проблемы будут. И вам придется их решать вместе.
|
|
|
+
|
|
|
+# Эпилог
|
|
|
+Если вам не удалось реализовать проект в рамках бюджета, бизнес-сроков и качеством достаточным для этапа проекта - вам не удалось его реализовать. Все остальное софистика.
|
|
|
+То же самое касается и поддержки. Если вы не можете внести необходимые для бизнеса изменения в сроки, которые требуются бизнесу - вы не можете его поддерживать.
|
|
|
+
|
