{"id":14286,"url":"\/distributions\/14286\/click?bit=1&hash=d1e315456c2550b969eff5276b8894057db7c9f3635d69a38d108a0d3b909097","hash":"d1e315456c2550b969eff5276b8894057db7c9f3635d69a38d108a0d3b909097","title":"\u041f\u043e\u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430\u0434 \u043a\u0440\u0443\u043f\u043d\u0435\u0439\u0448\u0438\u043c\u0438 \u0418\u0422-\u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c\u0438 \u0441\u0442\u0440\u0430\u043d\u044b","buttonText":"","imageUuid":""}

5 Фатальных ошибок стартапов глазами разработчика

Всем привет. Немного обо мне. Это мой первый публичный пост такого толка, поэтому прошу судить строго(нет). Я являюсь Старшим Full-Stack разработчиком в аутсорсинговой компании. Мой опыт разработки более 8 лет, в том числе и сотрудничество со стартапами. Хочу рассказать несколько основных ошибок стартапов, которые с большой долей вероятности приведут к провалу.

Надеюсь Вам будет не только интересна, но и хоть немного полезна эта информация.

Итак, начнем.

Бизнес взаимодействует с разработкой только в одном направлении.

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

Очень часто именно видение задачи со стороны разработки будет более верным, чем со стороны бизнеса. Самая распространенная ситуация это недооценка сроков и сложности задачи.

«This is simple» и «This is not a rocket science» должны говорить именно разработчики(в случае, если это конечно так) а не бизнес.

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

Бизнес навязывает технологии разработчикам - CEO виднее

Слабому - плеть, вольному - воля (с).

Самый распространенный кейс: CEO где-то услышал или кто-то ему посоветовал какую-то технологию и скорее всего очень популярную. После беглого и поверхностного изучения данный персонаж бежит в отдел разработки и начинает требовать повсеместной замены и внедрения данной технологии.

В чем проблема?

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

Проджекты и Продакты не нужны! Лучше наймем еще парочку разработчиков.

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

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

Со временем, кто-то должен начать заниматься вопросами организации процессов, а так же заведовать каналом связи по доставке идей из вашей головы в отформатированный на язык разработчика набор задач.

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

MVP из топора.

Не знаю почему для большинства стартапов это до сих пор звучит как откровение, но MVP должен быть MVP!

Не надо накидывать кучу разных хотелок и фич, причем одновременно.

Вот небольшая история как это бывает.

Некий «Персонаж» решил создать классный сервис для учителей, скажем календарь внеклассных событий с нотификацией родителей учеников по смс/email.

Казалось бы идея классная - бери и делай, но нет.

Тут же появляются "советчики", которые начинают предлагать всякие сомнительные идеи из серии систем машинного обучения для предсказания следующего внеклассного мероприятия, datascience для анализа "Огромного" количества записей в календаре и blockchain системы для децентрализации всей этой истории.

И вот это «Персонаж» начинает собирать команду супергероев: Senior data science - 300k, Senior ML engineer - 300k .... Вместо того чтобы нанять простого middle php разработчика и сделать MVP хорошо.

И рыбку съесть и косточкой не подавиться.

Желание максимально быстро получить большие деньги у большинства стартапов так велико, что они начинают забывать про то с чего все началось. И тут начинается поиск богатых "Инвесторов".

Это приводит к тому, что вместо развития продукта и улучшения его качества, написания тестов для кода и реализации новых полезных фич вся команда разработки занимается бесконечными демо и написанием непонятного функционала для них.

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

Заключение

Подводя небольшой итог хотел бы сказать что несмотря на то, что этим небольшим списком набор проблем не ограничивается, не надо полагать что вы обязательно их совершите. Как говорится, нормально делай, нормально будет. Будьте внимательными к своему проекту, имейте гибкое мышление, не отказывайтесь от помощи и советов, ведь именно Ваш стартап должен "Изменить мир к лучшему!") Всем лучи добра. Буду рад обратной связи.

0
2 комментария
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Иван Никитин
Автор

Согласен полностью!

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда