В вашем стартапе есть разработчики? С ума сходить, потому что понятия не имеешь, как управлять ими… судить о качестве их работы… обучать их постоянно меняющемуся продукту, который знаменует собой жизнь стартапа…?

Вот что вам нужно сделать.

Не только один из них.

Все они.

Я знаю. Это длинный список. Но все они идут рука об руку. Держись за меня, и я думаю, ты увидишь…

Частые (не реже одного раза в неделю) демонстрации

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

Смиритесь с тем фактом, что иногда они интерпретируют вещи иначе, чем вы, что вы имели в виду — это типично, потому что программное обеспечение сложное. Вот почему вы не можете позволить себе потерять больше недели из-за того, что разработчик идет не в том направлении. Я знаю, что стартапы безумно заняты, но отдавайте предпочтение демонстрациям. Выделяйте стандартный день/время каждую неделю и придерживайтесь его.

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

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

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

Но так быть не должно — это ваш стартап! Придумайте набор задач для разработчиков, где каждая задача — это то, что вы понимаете и что можно продемонстрировать в пользовательском интерфейсе (например, с помощью приложения). Таким образом, вы понимаете и контролируете задачи и можете оценить качество выполняемой работы с помощью еженедельных демонстраций.

Фокус! О ближайших приоритетах

Что часто случается со стартапами, так это то, что у вас есть основатель (обычно генеральный директор), который по понятным причинам взволнован своим стартапом и поэтому имеет бесконечный список замечательных вещей, которые будут делать их продукты.

И меняется каждую неделю.

Это очень бесполезно для разработчиков, которым нужно понять, на чем сосредоточиться СЕГОДНЯ, и которым нужно иметь возможность завершить одну задачу, прежде чем переходить к следующей, иначе ничего никогда не будет сделано, и все будут разочарованы и ненавидят друг друга.

Поработайте с разработчиками, чтобы понять, сколько времени это займет (не сходите с ума и не сводите все к минутам, просто ориентируйтесь), а затем выясните, какие из этих задач вы хотите, чтобы они сосредоточили на следующей неделе или двух. Не более того!!

Затем попросите их просмотреть список в порядке приоритета — продемонстрируйте, что они сделали в конце каждой недели.

Маленькие задачи, одна (и только) одна за раз

Чтобы это работало, каждая задача должна быть достаточно маленькой, чтобы соответствовать еженедельным спринтам (это означает, что функции будут разбиты на несколько задач). Поэтому работайте с разработчиками, чтобы сломать их. Разместите каждую задачу на своей канбан-доске:

И затем УБЕДИТЕСЬ, что, как только разработчик начнет задачу, он сможет ее ВЫПОЛНИТЬ, прежде чем вы дадите им что-то новое! В противном случае у вас будет 100 невыполненных задач, ни одна из которых не является конкурирующей, и ТОННА времени будет потеряна, чтобы вернуться к старой задаче, пытаясь вспомнить, что вы делали. И все будут ненавидеть друг друга.

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

Если все изменилось настолько сильно, что вам больше не нужна эта задача, уберите ее полностью — в том числе заставьте их вернуть свой код! а затем они могут начать на следующем.

Как раз вовремя код и рефакторинг

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

  • сверхгибкие (у них нет дополнительного кода, который им придется менять, когда неизбежно меняются приоритеты) и
  • очень быстро (они кодируют только необходимый минимум)

НО — чтобы это работало, вам нужно убедиться, что они (есть!) тратят время на рефакторинг кода перед добавлением каждой новой функции. Это означает, что часть работы по каждой новой задаче включает в себя рефакторинг кода, который они собираются затронуть, прежде чем внедрять функцию. Бонусом, если у них есть несколько автоматических тестов, которые помогут убедиться, что ничего не сломается при рефакторинге.

Если вы не позволите им сделать это — всегда вместо этого говорите: «Нам это нужно было еще вчера! нет времени на рефакторинг! быстрее!" тогда код превратится в такой беспорядок, что будет сложнее (и медленнее, и более подвержено ошибкам) ​​добавлять новые функции. И в конечном итоге дойдет до того, что изменить код практически невозможно, поэтому вам придется выбросить его и начать заново.

И все будут ненавидеть друг друга.

ПРАВИЛЬНЫЙ уровень качества для вашего текущего этапа

ЭТО СКАЗАЛ... иногда совершенно нормально иметь ужасный код, который вы просто набиваете так быстро, как только можете.

Стартап на очень ранней стадии, скорее всего, выбрасывает свою первую или три версии, где (даже если они не хотят этого признавать) основная цель этих первых версий — выяснить, что работает с клиентом и/или с технической точки зрения. перспектива. И ТОГДА вы можете построить правильную вещь. Так что делать код лучше — пустая трата времени. Просто выясните, что работает, а затем создайте ЭТО.

Вы просто должны понимать, что это имеет серьезные ограничения, и смиритесь с этим!

Преждевременная оптимизация и масштабирование — просто скажите «нет»

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

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

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

Важность мышления Startup/Agile для разработчиков

Вам нужно нанять/аутсорсить разработчиков, которые чувствуют себя комфортно в стартапах или супергибких средах и готовы работать быстро и аккуратно. Но по-умному (а не просто писать дрянной код! Потому что этот код будет ломаться снова и снова, и вы никогда ничего не добьетесь).

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

И вы получите идеально сделанный продукт, который никто не использует.