Советы стартапам: программирование

Это сборник советов, охватывающих создание программного обеспечения, инфраструктуры, PR, конференции, правовые и финансовые вопросы. Они описывают оптимальные методы работы на ранней стадии IT-стартапа. Мы надеемся, что вы найдете эти советы полезными, но помните, что они основаны на субъективном опыте, и не все из них будут применимы к Вашей компании.

1. У вас должен быть рабочий код.
   Рабочий код демонстрирует как возможности идеи проекта, так и способность команды в принципе строить работающие проекты. Работающий код является пусковой площадкой для вашего бизнеса, говорить о проекте можно только после демонстрации рабочего кода. Раньше технологические компании организовывались на основании идеи, кое-как сформулированной на клочке бумаги, теперь эти времена позади. Сегодня стартап для получения венчурного финансирования должен иметь не только работающую систему, но и некоторое количество активных пользователей этой системы.
2. У вас должен быть технический соучредитель.
   Каждый проект начинается с идеи и нескольких человек. В наше время многие из основателей таких компаний - технари, но так было не всегда. Всего несколько лет назад команды из программистов сталкивались с серьезными проблемами при поиске финансирования, ведь бытовало мнение, что только люди со степенью MBA в состоянии управлять компанией. Сейчас наличие технических специалистов среди учредителей рассматривается как преимущество.
3. Наймите программистов высокого класса.
   До недавнего времени строительство крупных, масштабируемых проектов было сродни черной магии. Большинство проектов разрабатывалось годами, в разработке принимало участие несколько многочисленных групп программистов, зачастую не находивших общего языка по поводу различных аспектов проекта. В результате часто получался кривой нестабильный продукт, который было трудно поддерживать и расширять. Проблема заключалась в том, что в разработке принимало участие слишком много специалистов низкой квалификации. Стартап не может позволить себе специалистов невысокого класса, это неизбежно скажется на результатах работы отдельных элементов системы или всего продукта в целом.
4. Не раздувайте состав группы разработчиков и не отвлекайтесь на аутсорсинг.
   2-3 звезды программирования в команде могут создать хороший продукт, потому что они специалисты в своей области, любят писать хороший код, сосредоточены на основной задаче и не отвлекаются на посторонние цели. Бригада из 20 человек может сделать меньше за то же время. Возможность масштабирования работ не реализуется лишь путем увеличения количества разработчиков. Истина заключается в том, что наиболее успешные современные программы написаны горсткой программистов. Лучше меньше да лучше - это относится в равной степени и к количеству разработчиков, и к объему написанного ими кода.
5. Создавайте жесткие условия для принимаемых в команду.
   Нет ничего хуже, чем быть нетребовательным в ходе первоначального интервью с претендентом, и в результате получить в команду слабого игрока. Это плохо для бизнеса, и это плохо для нанятого человека. В итоге вам все равно придется расстаться, но ведь лучше было бы не начинать такое сотрудничество, закончившееся обоюдным разочарованием. Поэтому необходимо занять жесткую позицию и задать массу технических вопросов в ходе интервью.
6. Избегайте найма менеджеров широкого профиля.
   Для небольшой команды разработчиков не нужны специалисты такого типа. Если каждый в команде точно знает что ему делать - то зачем нужен менеджер? Общее руководство в данном случае только замедлит процесс. (по-моему, это ошибка, хороший менеджер проекта еще никогда не мешал делу, другое дело, что его функции должен выполнять кто-то из команды - прим. пер.)
7. Поощряйте гибкость.
   Современные стартапы должны быть очень маневренными. Нет места полугодовому планированию, потому что кто-то может успеть сделать аналогичный проект за месяц и прийти к финишу раньше. Новый подход в том, чтобы быстро создать работающий прототип. Конечно, вы занимаетесь планированием следующего релиза, но вы не тянете с выпуском новой версии продукта, и регулярно выпускаете свежие билды.
8. Не изобретайте велосипеды.
   Множество стартапов идут ко дну со своими собственными фреймворками. Обычно их бывает 2 типа - заново переписанные (по образцу существующих - прим. пер.) библиотеки и чуть ли не полностью созданные языки программирования. Существует множество замечательного качества библиотек с открытым кодом, умнее будет использовать готовые решения, нежели воссоздавать их заново - вы же не печете хлеб и не сбиваете масло для бутерброда на завтрак каждое утро?

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