Операционные и технологические проблемы IT стартапов

Сергей Петров и Пётр Коротков из компании MISolutions рассказали нам, какие ошибки в разработке чаще всего допускают начинающие стартапы и как с ними бороться.

Пётр Коротков (COO), Сергей Петров (CEO) и Юрий Цапков (CTO)

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

Немного истории. Наша компания не так давно на рынке, и изначально мы позиционировали себя, как студия мобильной разработки, оказывающая услуги в основном по «сервисной» модели.

Как мы понимаем «сервисную» модель: к вам приходит клиент с ТЗ или ФТ, или общим описанием проблемы, которую надо ему решить, а вы предлагаете ему решение «под ключ»: от этапа проектирования до тестирования и приемо-сдаточных испытаний. Если проблема достаточно четко описана – то можно применять стандартный метод «waterfall», если проблема не очень понятна (когда клиент сам не до конца понимает, какой результат хочет получить) и нужно структурировать его «поток сознания», то применяем гибкие подходы к управлению проектом со всеми вытекающими.

Выполнив несколько проектов по «сервисной» модели мы поняли, что у нее, разумеется, есть свои плюсы и минусы, но при этом она не дает реализовать весь экспертный потенциал, которым мы располагаем в сфере разработки, операционного управления и продуктовой аналитики. В результате, приняли решение попробовать себя в роли аутсорс-команды разработки для IT-стартап проектов. Чуть более, чем за полгода нам удалось поработать с 4 различными стартапами и выявить их классические проблемы, о чём мы с радостью и расскажем.

Технологические проблемы

1. Две крайности проектирования

Одна крайность – давайте быстро сделаем что-нибудь и как-нибудь, и заработаем кучу денег. И в данном случае справедлив тезис «shit in – shit out»… Неопределенность на входе приводит к такой же неопределенности на выходе, бесконечным метаниям в выборе платформ и фреймоворков и, в итоге, к смене команды проектирования и разработки.

Вторая – давайте сделаем идеального сферического коня в вакууме, который: а) не нужен конечному пользователю, так как ценностное предложение и бизнес-модель не продуманы и не оттестированы – зато очень хорошо продумана архитектура, детализованы все схемы и блок-схемы, описаны интерфейсы, все красиво, чисто и мертво, как дохлая лошадь; б) обходится очень дорого инвестору, поскольку делается на самом дорогом оборудовании и с колоссальными трудозатратами, за которые платит опять же владелец бизнеса, а терпение у такого владельца совсем не резиновое.

2. Неправильный выбор стека технологий и сопутствующие проблемы с масштабированием и развитием проекта

Стек технологий выбирается не с точки зрения оптимального и эффективного решения задачи, а исходя из компетенций команды разработки. Классический пример, когда важна последовательность решений. ВАЖНО, как мы приходим к разработке и от чего отталкиваемся. Из опыта экспертов рынка, а также коллег по цеху, правильная последовательность такова:

• Бизнес требования
• Продуктовые требования
• Проектирование архитектуры решений
• Подбор соответствующих персоналий для реализации
• Собственно реализация

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

3. Сложность и громоздкость выбранного архитектурного решения

Она тянет за собой: высокую стоимость его поддержки и, в случае разворота модели, как минимум большие издержки на переформатирование и перестройку/перенастройку, а как максимум – пересмотр архитектуры и перестроение ее «с нуля». Это в итоге опять же выливается в доп. затраты, которые оплачивает инвестор.

4. Эксперименты с новыми технологиями

Платформами, фреймворками, языками программирования. Программисты – люди увлекающиеся! Им только дай волю – все время потратят на эксперименты. В итоге фокус смещается с работы над задачами на прокачку скиллов и поиск новых решений. Время уходит, задачи не выполняются, инвестор расстраивается, а ваш проект начинает разваливаться. Ответственность за выбор технологии (в том числе и экспериментальной) несёт главный технический специалист стартапа (СТО и/или архитектор) и неправильный её выбор сразу говорит об уровне его компетенции. Решить эту проблему можно только одним способом: пригласить в стартап нового эксперта.

Операционные проблемы

1. Выбор неправильной модели управления проектам или неправильное применение существующих методов

С чем конкретно нам пришлось столкнуться?

• Многие применяют гибкие методы управления, забывая о классике: календарный план-график. Чаще всего задачи имеют ограниченный срок реализации, а этот инструмент позволяет хорошо отслеживать общий прогресс проекта и видеть зависимости, цепочки задач, позволяет осуществлять прозрачный контроль за процессом.
• Не всегда применение гибких методов оправдано. В некоторых случаях правильнее применить модель управления «waterfall». Например, когда сроки и постановка задачи жестко определены.
• Применяя SCRUM часто забывают про такие важные принципы, как приоритизация задач, неизменность состава и описания задач в процессе спринта, ретроспективный анализ. Это приводит к таким ожидаемым проблемам, как миграция ошибок из спринта в спринт, регулярные переносы задач в следующий спринт, концентрация на фичах, а не на важном функционале.

2. Подбор кадров с низким или недостаточным компетенциями

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

• Например, управляющие не понимают, что смысл стартапа — это поиск потребителей и продукта или услуги для них, и нужно гибко подходить к управлению организацией, принимать обратимые решения и смотреть на отклики потребителей. А управляющие мыслят понятием “бизнес план” и слепо следуют этому плану, в результате чего снова создают ненужный потребителю продукт и в качестве итога имеют остановку в развитии или полное закрытие проекта.
• Простой набор персонала для работы над стартапом. С одной стороны это должны быть надежные и проверенные люди, с другой — заряженные на работу и готовые терпеть неудачи, поскольку стартап — это постоянный поиск успешной бизнес модели через множество неудач.
• Ещё одной частой проблемой является непонимание инвестором самой сути проекта. Инвестор зачастую думает только о том, когда он вернет свои вложения и получит прибыль. Он не понимает, что к стартапу не применимо понятие бизнес плана. Стартап — это поиск воспроизводимой масштабируемой бизнес модели. Бизнес модель можно не найти никогда. И инвестор своими постоянными требованиями «когда я получу прибыль» заставляет принимать решения, которые и ведут к гибели стартапа. Например, слишком быстрый вывод продукта на рынок.

3. «Хаос в головах – хаос в проекте»

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

• Нельзя создать порядок в реальном мире, если внутри головы – хаос.
• Многие берутся за большие задачи и не справляются с ними в заданные сроки, что приводит к спаду мотивации и ошибочным выводам. СДЗ (структурная декомпозиция задач) – супер-инструмент.
• Частая ошибка — отсутствие четкого плана, роад-мэпа даже на ближайшие сроки. Без плана как без карты: путь из точки А в точку Б – это событие, имеющее низкую вероятность положительного исхода.

4. Отсутствие порядка в ведении протоколов встреч, совещаний, версионности документов, требований, фиксации договоренностей

• Порядок, документирование и фиксация договоренностей, изменений и т.д. очень важны, поскольку позволяют в любой момент времени вернуться к исходной или к любой другой точке в проекте, выявить ошибочные предпосылки, выводы и начать не «с нуля», а с промежуточной точки, уже имея опыт, который был получен в процессе.
•  Фиксация договоренностей на бумаге (или в электронном документе) поможет избежать разногласий, когда придет время делить прибыль или доли в бизнесе. В новых проектах часто забывают об этом пункте, надеясь ускорить процесс получения прибыли через отказ от бумажной волокиты.

Резюме

Всем IT-проектам нужна удача и лояльный инвестор :).

Наши советы:

• Выбирайте лучшие кадры на руководящие позиции, особенно CTO и COO. Это позволит минимизировать ошибки и ускорит прогресс. COO – must be в любом проекте.
• В проектировании придерживайтесь баланса: идеальных проектов не бывает, все равно что-то придется пересматривать и переделывать, и может быть даже не один раз. Однако и «забивать» на этот этап чревато серьезными последствиями.
• Принимайте решение о стеке технологий на этапе проектирования, когда уже понятны бизнес и продуктовые задачи проекта. Выбирайте проверенные архитектурные решения.
• В начале проекта – наведите порядок в голове, положите мысли на бумагу, нарисуйте mind-map карту и чётко структурируйте для себя тот проект, который задумали.
• Подготовьте план, роад-мэп, как пойдете, продумайте сценарии.
• Декомпозируйте большие блоки работ на более мелкие с измеримыми и явными сроками и результатами.
• Регулярно фиксируйте все договорённости, изменения проектной документации, протоколы встреч. Ведите реестр документов. Пользуйтесь системами электронного документооборота, где ничего не потеряется.