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

Содержание:

  1. Коммуникация с программистами. Как практики стартапов могут помочь ставить задачи
  2. Как правильно ставить задачи

Коммуникация с программистами. Как практики стартапов могут помочь ставить задачи Как ставить задачи

Зачем долго тянуть время, чтобы сделать все через “жопу”? Лучше сразу сделать через “жопу” и еще время останется все исправить

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

В бизнесе нужно фокусироваться на том, что ты лучше всего умеешь. Остальное - аутсорс.

Допустим, у вас были причины, чтобы взять программиста или комманду программистов к себе в штат. Что с ними делать дальше? Как быть? Как практики стартапов помогут вам экономить на разработке и работать более эффективно?

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

С этим отлично помогут практики Lean Startup и Agile. Даже, когда у вас не стартап, эти моменты будут работать.

Что такое стартап?

Мы наблюдаем постоянно кучу стартапов. Некоторые выстреливают, некоторые умирают. Но почему оно так? Почему 9 из 10 стартапов обречены на провал? У каждого стартапа есть план, но Майк Тайсон говорил, что у всех есть план до первого удара.

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

Бизнес-модель - это ответ на вопрос “Как вы будете зарабатывать деньги”,

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

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

Принципы бережливого стартапа

Начнем с того, что у стартапа всегда ограничены ресурсы. Это может быть финансовые, человеческие и любые другие ресурсы. Методология Lean стартап нацелена на то, чтобы пройти максимальное количество итераций, до тех пор, пока не закончились ресурсы. У Lean стартапа есть пять принципов:

  1. Предприниматели есть везде. Предпринимательство - это лишь способ мышления и последовательность действий, которая может быть применена где угодно.
  2. Предпринимательство - это менеджмент. Менеджмент - наука о управлении ресурсами. Каждый предприниматель - управленец по натуре.
  3. Знание - это результат проверки гипотез. Любой стартап заключен в ряд гипотез. Гипотез о том, кто является клиентом, какую проблему он решает, какую ценность несет.
  4. Никакое развитие не возможно без накопления знаний. Накопление знаний - самое важное в методологии Lean.
  5. Цикличность и последовательность проходжения проверки гипотез.
    1. Build -> Product
    2. Measure -> Data
    3. Learn -> Ideas

Или по русски если Создать/Провести эксперимент -> Собрать метрики -> Изучить Билд - проведение эксперимента. На первом этапе - это может быть что угодно: MVP или Landing page. Далее мы собираем метрики. Метрики важнейшие показатели. Они показывают всегда то, что на самом деле происходит. На следующем этапе мы изучаем метрики и понимаем, что мы сделали в результате. На этом этапе мы делаем выводы, формируем новые гипотезы, делаем новый MVP, делаем новый продукт или продолжаем развивать текущий.

По такому циклу нужно проверять новую гипотезу. Цикл всегда неизменный. Всегда по такому пути мы проверяем каждую новую гипотезу/идею.

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

Ну ок, идеи я отсеял более менее. А дальше что?

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

ОК, лендинг сделали, евангелисты есть, пару MOU подписаны, дальше то что?

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

Почему?

  1. Вы можете рассписать подробную задачу, которая будет полной. Вы думаете, что рассписав ее и сделав ее один раз, вы больше ее делать не будете.
  2. Не проходя по пути MVP у вас больше рисков, что изначальное ТЗ было ошибкой.
  3. Вы потратите больше времени разработчика. А время разработчика - это потраченные деньги.

Идя по пути MVP и мелкими шагами, что вы получаете:

  1. Продукт, который действительно нужен вашим клиентам.
  2. Разработчик тратит время эффективнее, потому что не делает не нужную работу.
  3. После каждого спринта/цикла у вас есть готовый продукт, который возвращает вам деньги.

Ок, с этим разобрались, но дальше что?

Всегда, когда вы поставили задачу программисту - вам нужно нести отвественность за запуск этой задачи в продакшне и отбивать инвестиции, затраченные на разработку. Вам тут нужен скилл в Getting Things Done.

Вы всегда в таком расширенном цикле:

  1. Получить понимание, что задача нужна клиенту
  2. Получить первых евангелистов
  3. Поставить задачу на разработку.
  4. Дождатся поставки готовой задачи на продакшн
  5. Внедрить в текущие ваши административные и продуктовые процессы.
  6. Собрать метрики эффективности
  7. Сгенерить новую идею
  8. Перейти в пункт 1.

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

Всегда доводите дела до конца. Всегда планируйте мелкими итерациями. Идите по пути эволюции и взращивании вашего продукта. А вывод отсюда простой: “Зачем долго тянуть время, чтобы сделать все через “жопу”? Лучше сразу сделать через “жопу” и еще время останется все исправить”

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