Команда - це один з найбільш ризикових компонентів ІТ-стартапу. Якою вона має бути?
По-перше, укомплектованої. Це означає, що в команду повинні входити техлід, бекенд- і фронтенд-розробники, дизайнер, тестувальник, системний адміністратор, менеджер. З іншого боку, чим менше команда, тим більше функцій поєднує в собі один чоловік - це, в общем-то, непогано, але тільки на самих ранніх стадіях проекту, коли важливо швидко зробити першу версію, не витрачаючи час на бюрократію, сторонні справи і допитливе планування.
По-друге, спрацювала. Внутрішньокомандні непорозуміння - як пісок в годинниковому механізмі. Звичайно, з часом будь-яка команда здатна «притертися», але наслідки від самого процесу можуть бути непередбачуваними.
По-третє, і це бажано, зібраної в одному приміщенні. Але це вже в окремий пункт.
Є кілька типів команд, і у кожного свої особливості.
розподілена команда
Коли дизайнер в Києві, програмісти в Мумбаї, а ви в Москві. Або навпаки, не має значення.
- Можна знайти оптимальне співвідношення ціна-якість під свій проект
- Не треба платити за офіс
- Не потрібно обмежуватися кадрами з вашого міста / регіону при формуванні команди (актуально, так як хороших кадрів на ринку дійсно мало)
- Важко контролювати людей
- Є незручності, пов'язані з часовими поясами
- Стереотипний образ безвідповідального фрілансера-удаленщіка часто підтверджується
- Складнощі із залученням коштів: інвестора швидше зацікавить проект зі стабільною командою «тут і зараз»
Нерозподілений команда в офісі
Оптимальний варіант для стартапу: всі сидять під одним дахом і роблять спільну справу.
- Зручно контролювати і управляти
- Команда переймається духом проекту
- Можна оперативно проводити колективні брейншторм
- Можна швидко впроваджувати нові ідеї в проект
- Своя команда привабливіше для інвестора
- Витрати на офіс, техніку, обслуговування і т.д (часто це найдорожчий варіант)
- Людський фактор: люди можуть звільнитися або захворіти на пару тижнів
- Потрібно організувати процес навчання
- Потрібно щільно займатися HR (в тому числі - швидко заповнювати втрати в загоні)
«Оренда» нерозподіленого команди
Команда фізично знаходиться в одному офісі, але не в вашому.
- У вас в розпорядженні готова спрацювати команда
- Підрядник бере під свій контроль питання HR, заміну співробітників
- Можливість «зібрати» будь-яку команду під ваші потреби
- Підрядник вирішує питання швидкого масштабування команди (зняти з проекту зайвих людей або розширити команду в два рази)
- Структура витрат зрозуміла і всі ризики закладені в фінальну вартість команди
- Складнощі віддаленої комунікації (якщо підрядник в іншому місті)
- Послуги готової команди будуть дорожче послуг фрілансерів
- Низька емоційна залученість команди в проект
Іншими словами, потрібно виходити з потреб і можливостей - тут немає нічого хитрого.
Є два типи: за факт здачі проекту і за час.
У випадку з фіксованою оплатою за проект все зрозуміло: підрядник здає проект, замовник приймає, гроші перераховуються. Можливо, частинами і з передоплатою. Схема працювала б ідеально, якби завдання були строго визначені на старті, вимоги не змінювалися і кінцевий результат з імовірністю 100% відразу б приймався замовником (адже він не відступає від ТЗ).
В реальності ж, тим більше в розробці стартапів, все складніше. Особисто наш досвід говорить про те, що через 1-2 місяці роботи сам замовник більше вникає в тему, змінюються пріоритети проекту, з'являються нові завдання. Це просто неминуче, і до цього треба бути готовим. Фіксованою таку схему оплати можна назвати з дуже великими застереженнями.
Тому, коли вам називають жорстку суму після оцінки, - не вірте. Кращий спосіб вирішити такий конфлікт - почати працювати по фіксованій оплаті, перевірити команду в дії, щоб згодом перейти на погодинну оплату.
Оплата за час і ресурси (Time Material) - це погодинна оплата праці задіяних в проекті фахівців, «мізки в оренду по годинах». У кожного фахівця свій рейт (вартість години): керівник проекту коштує дорожче програміста, програміст дорожче тестувальника і так далі. З одного боку, схема зручна для стартапів: виникли нові побажання, захотіли щось переробити - будь ласка, платіть за тарифом, не обов'язково все враховувати в оцінці на старті. Але є і складності. Так, наприклад, схема вимагає певного рівня довіри між замовником і виконавцем, в іншому випадку будуть виникати неминучі розмови із серії «а що це ви так повільно працюєте, я ж вам гроші плачу!».
Інші важливі недоліки погодинної оплати:
- Команда, яку беруть в оренду по годинах, що залишилися годинник працює на інших проектах. Концентрація пропадає, і отримати стовідсоткову віддачу від людей стає неможливо.
Оренда команди на фіксований термін (наприклад, місяць). Більш краща схема, у вас з'являється закріплена за вами команда потрібних фахівців, вартість яких розраховується за формулою «собівартість + націнка». Команда працює виключно над вашим проектом і готова в робочий час вирішувати будь-які завдання. Крім того, багато команд дають знижки, якщо їх наймають «оптом».
Є одна маленька, але дуже важлива деталь. Називається «завантаженість фахівця».
З нашого досвіду - робоча команда з 5 чоловік стоїть 450-550 тисяч рублів на місяць.
Ризиків багато. наприклад:
- Відсутність контролю за розробниками
Наслідки можуть бути досить неприємними: від постійного рефакторінга коду до експериментів програмістів з «новими цікавими технологіями». В результаті через півроку доведеться розгрібати наслідки експериментів.
- Проект ось уже 6 місяців знаходиться у фазі «зроблено на 80%, запуск через 2 тижні»
Через неправильно побудованої архітектури проект з кожним місяцем може робитися все довше і довше. Причина неправильної архітектури - не тільки недалекоглядність програмістів, але часто і постійні зміни концепції проекту. Наприклад, сервіс, який спочатку був для читачів книг, потім раптом вирішили переробити під видавців. Аудиторія змінилася, а архітектура - немає. Якщо кожна нова задача робиться все довше і довше, кожне виконане дію породжує одну або кілька нових помилок - це перший симптом описаної проблеми.
- Проблеми з людськими ресурсами
Хтось може звільнитися, захворіти, а кому-то пообіцяють кращі умови в іншому стартапі. Коли програміст йде з незакінченого проекту - залишається недописаний код. Щоб знайти кодеру заміну, йде в середньому 2 місяці. І ще стільки ж піде у нього на те, щоб новий співробітник міг освоїтися на проекті. І не факт, що його все влаштує і він залишиться в команді (або - що він влаштує вас).
- Недостатньо уваги QA
Тестування - мало не ключове завдання команди проекту. Часті зміни в коді гарантовано ведуть до виникнення помилок, незалежно від якості кадрів. Якщо немає тестувальника (а краще кількох) - помилки будуть нашаровуватися один на одного, а відловлювати їх причини з часом стане все важче. Програмісти можуть говорити про автотестування, але Автотест забезпечують перевірку на стороні бекенд і не знаходять проблем типу «кнопка сповзла вліво».
Ризики стартапів - це окрема тема для важкої статті. Або навіть книги. Тому дуже загострюватися на ній не будемо, докладніше розповім наступного разу.
Всі вже більш-менш в курсі, в чому різниця підходів. Але про всяк випадок коротко пояснимо.
Waterfall (або «водоспадна» модель)
Це коли проект розробляється цілком, неітеративному. Передбачає написання всеосяжної документації та чітко визначених цілей проекту.
- Чітко визначені цілі, стабільні вимоги
- Процес розробки легко зрозумілий і добре структурований
- Жорсткі тимчасові рамки
- Прогнозованість витрат часу, ресурсів
- Необхідність визначити функціональність проекту вже на етапі попереднього обговорення
- Неповороткість проекту, непристосованість до швидких змін
- Довга і дорога розробка технічної специфікації проекту (яка вже через два місяці неактуальною)
Agile (або «гнучка» модель)
Коли проект розробляється невеликими етапами, цілі змінюються на ходу, документації приділяється менше уваги.
- Поетапність, ітеративний, видача функціонального проекту невеликими «порціями»
- Можливість швидкого запуску на ринок
- Ранні коригування проекту з урахуванням зворотного зв'язку кінцевих користувачів
- Легко змінюються пріоритети без шкоди робочому процесу і бюджету
- Імовірність «нескінченної» розробки зважаючи на невизначеність кінцевих цілей
- Постійно зростаючий «технічний борг». Часто при гнучкому підході прагнуть запустити ще сиру версію продукту, відкладаючи доведення до розуму на потім. У підсумку це може вилитися в накопичення так званого «технічного боргу», який підрядник не завжди в змозі «виплатити»
- У критичний момент може не виявитися актуальною документації по проекту, якщо їй не приділялося достатньо уваги
Не можна однозначно називати будь-якої підхід хорошим або поганим. Одна і та ж команда може працювати по agile або waterfall по-різному. Але гнучкість для стартапів все ж приоритетнее стабільності - так, вже зміцнілі проекти переходять на ще більш гнучкі моделі розробки (наприклад, DevOps, де сотні змін вносяться в проект щодня, запускається безліч A / B-тестів і експериментально з'ясовується, що більше подобається користувачам) .
На це питання вже було дано часткову відповідь.
HR - дуже проблемне місце для стартапу. На початку, крім рекрутингу, у вас буде достатньо головного болю. Але і набір команди - той ще квест: кадрів на ринку мало. Варіант з вирощуванням власних фахівців стартапу не підходить: це довго, а нам потрібен швидкий зліт. Ханти з інших проектів? Або у вас повинен бути дуже цікавий і перспективний проект, або у вас повинен бути дуже товстий гаманець.
Навіть якщо у вас все вийшло і ви набрали свою першу команду - хто сказав, що ці люди спрацюються? Що вам не знадобиться замінити когось? Або добрати ще фахівців? А якщо людина раптом захворіє або звільниться? Він взагалі може просто по-тихому злитися, особливо якщо ви працюєте з удаленщікамі. Все це не варто випускати з уваги.
Про те, на що звертати увагу при пошуку людей, а також про плюси і мінуси своєї команди і «команди в оренду», ми писали у відповіді на питання 2.
Звичайно, питання суто індивідуальний, проте деякі типові терміни є.
Ми виділяємо такі віхи в розробці стартапа:
- 1,5-2 місяці - терміни запуску MVP (мінімально функціонального продукту) Такий можна запускати з закритим або обмеженим доступом, перевіряти на кроликах і робити висновки про подальший розвиток.
- 4-5 місяців - терміни запуску фінальної версії проекту будь-якої складності
В більшості своїй вимоги до проекту змінюються після запуску MVP і оцінки наслідків. Тому - ні, не варто.
До речі, відвідуваність в 50 000 чоловік на добу - це не привід для паніки, їх комфортно витримає і один хороший сервер.
Пам'ятайте, що кожен учасник команди переслідує свої корисливі цілі. Навряд чи ви зможете створити у людей таку ж мотивацію, як особисто у вас. Програміст віддасть перевагу працювати з цікавою йому технологією, а дизайнер з радістю викладе новий інтерфейс на Behance. такі у них цілі, відмінні від мети стартапу.
Найбільш очевидний спосіб не допустити ситуації, коли на ваш бюджет розробники освоюють незнайомі технології - договорити про технології «на березі». Наявність у вас техліда буде великим плюсом. Спеціалізація команди на певних технологіях (наприклад, Ruby, Python і PHP для вебу, Swift для iOS, Java для Android) - ще один плюс.
Як побажання: не варто чіплятися за модні нові технології. Мов та фреймворків сьогодні безліч, але немає ніякої гарантії, що вони будуть жити і про них пам'ятатимуть через рік-півтора. Навряд чи вам потрібен проект, написаний за допомогою мертвих технологій.
Ключовий критерій для стартапу: технології повинні бути такими, щоб можна було швидко знайти заміну команді в майбутньому.
Порівняння ризиків при використанні різних видів команд і схем роботи.