Disclamer: я не создал стартап, но приходилось как оказаться изнутри, так и понаблюдать снаружи. Так что изложенные ниже мысли сугубо субъективны и адресованы тем, кто пока еще хочет запустить свой проект.
Представьте себе такую очень оригинальную ситуацию: вам до тридцати, и вы решили сделать стартап. Ммм, слово “сделать” – как-то грубовато звучит, правда? Это же хай-тек, это же инновации, это торжество человеческого интеллекта и трудолюбия, которое не иначе как должно изменить мир… Или принести вам миллионы денег. Пусть будет – “создать”.
Не будем разводить демагогию на тему “как правильно пить кофе с инвесторами” – представим себе фантасмагорическую ситуацию: вы решили создать все действительно с нуля. Без чьей-либо посторонней помощи. И у вас есть пул людей, из которых вы можете себе выбрать команду. И все они такие же, как и вы, кристально чистые идеалисты, которые обожают свое дело, мечтают воплотить свои таланты в жизнь и постоянно готовы учиться новому. Так как же максимально эффективно использовать все эти прекрасные ресурсы?
Как рыба гниет с головы, так и мы начнем с самого верху – с вас, дражайший, с идеолога и вдохновителя, IT-революционера с горячим сердцем и холодной головой. А если по-простому, то вы – продакт-менеджер и полностью несете ответственность за качество вашего продукта и его позицию на рынке. Кроме вас, по большому счету, никто в нем не заинтересован, и никто не будет жадно ловить каждое ваше слово и моментально воплощать его в идеальный код за гениальным дизайном. Значит – вам нужно четко ставить требования. Бизнес-требования. Значит – много писать, много и качественно, чтобы на их основе потом появились функциональные требования (которые, по большому счету, тоже вам нужно писать, но так и быть – пожалеем). Как минимум, вам нужно знать, в чем разница между СУБД и языком программирования, быть талантливым прозорливым руководителем и слышать каждый шорох в вашей команде, притом не заглядывая им через плечо – они этого ой как не любят. Исходя из начальных условий – они напишут все, что угодно, только поставьте четко задачу. А этим уже займется ваш проджект-менеджер.
Помимо тончайшего чувства времени, необходимого для рационального итерирования ваших гениальных планов и торможения вашего полета мысли (если вы на него еще будете спосбоны после выполнения ваших обязанностей), в принципе, он может и писать вышеупомянутые функциональные требования. То есть, ему неплохо знать, что такое UML, хотя бы догадываться о том, что архитектура – это не только что-то связанное с домами, и, опять-таки, быть незаметным, чтобы не мешать Творцам вашего никомуненужного гениального замысла.
К ним и перейдем, потому что без них вам лучше дальше хипстаграммить и потреблять направить вашу бурную молодую энергию в более общественно полезное русло: открыть ларек с шаурмой возле метро или отправиться с миссией Красного Креста куда-нибудь в Индонезию. И так слишком много уже на операционные расходы ушло.
Дизайнер. Еще не так давно к представителям этой профессии относились едва ли не как к чернокнижникам в средние века, считая их ремесло (подчеркиваю) чем-то шарлатанским. Нынче в сознании масс сложился диаметрально противоположный образ. А дизайн должен решать вполне конкретные задачи, притом самые разноплановые, зачастую быстро меняющиеся, потому и дизайнеру неплохо было бы работать, а не пялится в окно в поисках вдохновения. Еще каких-нибудь пятнадцать лет тому назад дизайнер был и юзабилистом, и собственно дизайнером, и верстальщиком, да и от копирайтинга корона с головы не падала.
И вот, наконец, сердце, руки и вашего проекта – разработчики. Ни в коем случае нельзя жалеть на их количестве (по большому, счету, да и на качестве, но, к сожалению кристально чистых бессеребников среди качественных программистов не так уж и много), но минимальнейшее количество – двое. Минимальное – четверо. Пара работает над следующей итерацией, вторая – отлаживает нынешнюю, потом меняются. Разработчиков не в чем упрекнуть – они действительно пишут код и натягивают на него дизайн. Если они пришли в ваш проект – им плевать, какого цвета и с какой стороны должна быть кнопочка “Use”. А если даже и против – настаивать сильно не будут. Но вот если станет вопрос, писать ядро на PHP или Django – лучше сразу сходите на встречу с инвестором проведите анализ конкурентов, чтобы не успеть почувствовать себя бездарной безрукой человекоединицей. Если не человеконулем.
Четыре – это только для ядра. Еще же нужны мобильные приложения, инфраструктура…
Последним ошибается только голкипер. На воротах у вас будет стоять тестировщик (тестер – это прибор такой для измерения электрофизических параметров). В творческом порыве разработчики вполне могут забыть о 49-м пункте функциональных требований или на 27 пикселей левее заверстать пресловутую кнопку “Use”. Первый пользователь вашей системы – злой гений и ангел-хранитель, опускающий на землю и оберегающий от трагических падений.
Это я все к тому, что при запуске стартапа вам могут быть не нужны сотрудники, которые “есть у всех” – есть небольшие компании, у которых вообще нет операционных расходов. Едва где-то начинает пахнуть деньгами – сразу найдутся шарлатаны, которые будут много и красиво говорить длинные речи с обилием англозвучащих слов, чтобы показаться умнее. Гоните таких в шею с порога. Профессионал приложит все усилия, чтоб быть понятым, иначе грош цена его знаниям.
А вообще, если можно не писать – не пишите. Если хотите много денег – пойдите работать в большую компанию и пашите, пашите, пашите. Если хотите изменить мир – закройтесь дома, занавесьте шторы и пашите, пашите, пашите. Правда, есть что-то общее?
Автор: CheG
