Совсем один: запуск онлайн стартапа без привлечения инвестиций и команды
Я до сих пор не могу объяснить, откуда приходит осознание необходимости начать свое дело. Кем бы ты ни работал, сколько бы ты ни получал, ты никогда не защищён от этого – чувства, которое начинает точить тебя изнутри, не давая спать по ночам: «Почему ты до сих пор не сделал что-то своё?». Дело не в деньгах. Несколько моих знакомых, номера телефонов которых почти что совпадают с их ежемесячными зарплатами, внезапно приходили к мысли, что, проработав «на дядю», они пока не добились ничего.
Желание открыть собственное дело дремлет до тех пор, пока ты не замечаешь пустующую нишу. Так сложилось, что в силу ряда причин я был косвенно погружен в сферу лингвистических переводов. Я занимался ими сам в качестве подработки, я хорошо знал, как устроена работа бюро переводов, я знал, как думает профессиональный переводчик, и – самое главное – чем недоволен клиент, которому в сложившейся системе порой не уделяют должного внимания. Иными словами, для запуска стартапа у меня было больше причин, чем даже у Игоря Николаева.
Чуть менее года назад я принял решение действовать. По своим знаниям, финансовым и техническим возможностям я, как мне кажется, не выделялся из множества одержимых подобной идеей. Не выделяюсь и сейчас, за тем исключением, что я попробовал – мой проект AnyLanguage, позволяющий быстро и качественно получить перевод любого типа, уже запущен для переводчиков и скоро будет доступен для клиентов. Тем не менее, считая себя не обделённым умом и интуицией, я умудрился заметно пополнить личную коллекцию подводных камней новыми экспонатами, некоторыми из которых хочу с вами поделиться.
ВЫБОР ВЕБ-СТУДИИ И ПОДПИСАНИЕ ДОГОВОРА
Почти в любом стартапе нужен сайт или мобильное приложение. Здорово, если у вас есть технический специалист, который станет частью команды и возьмёт эти задачи на себя. Если его нет, это не значит, что нужно его срочно искать – как я заметил, люди присоединяются к проекту охотнее, когда уже есть что показать, а те, кого вы нашли на этапе идеи, могут с лёгкостью соскочить. Поэтому на первых порах я решил заменить такого специалиста деньгами, заплатив за сайт веб-студии. Имея хотя бы прототип сайта, найти специалиста в команду вашего стартапа будет проще.
Выбор веб-студии и вопрос «Сколько стоит сайт?» достоин отдельной статьи, если не исследования. Я лишь дам несколько советов из опыта поиска исполнителя для AnyLanguage.
Составьте подробное ТЗ и обзвоните как можно больше веб-студий
Я знал, что чем подробнее будет составлено мое ТЗ, тем меньше вопросов возникнет при его реализации и тем точнее будет выставленная цена. Я неформально, но очень подробно описал весь необходимый AnyLanguage функционал, отобрал более чем 50 веб-студий и постучался в 30 из них с этим ТЗ. Это помогло понять реальную картину рынка и узнать актуальные технологические тренды.
Смотрите не на цену, а на то, кто её выставляет
Поразительно, разброс в ценах был на порядок. И здесь важно понять, кто среди откликнувшихся вчерашний школьник, кто демпингующий ради портфолио энтузиаст, кто профессионал, а кто – сытый профессионал, имеющий возможность позволить себе работать на личных условиях. Мне было проще всего это узнать, поговорив хотя бы 15 минут по телефону.
Забудьте тех, кто втюхивает популярные CMS
Мне встречались студии, которые предлагали разработку на базе WordPress, Drupal, Joomla и прочих CMS. Я сразу отказывался. Если функционала этих платформ хватает, чтобы удовлетворить ваши потребности, вы скорее всего сможете воспользоваться ими сами с минимальной помощью. Для этого их и писали – сейчас возможно за полчаса сваять сайт-визитку, блог, форум и даже соцсеть или интернет-магазин. Но скорее всего вам нужно то, что в прайс-листах числится как «custom». Для этого нет готовых решений.
Забудьте тех, кто умничает
Мы живём в век open source – никто никогда не создаёт сайт с нуля. Работа веб-разработчика заключается в грамотном совмещении актуальных технологий, поэтому следует работать с людьми, которые это открыто признают. Пропускайте тех, кто говорит, что у них собственная уникальная веб-платформа – в лучшем случае, это чужой фреймворк, изменённый так, что более не совместим с официальными обновлениями и содержит дыры в безопасности. В худшем – просто вранье. Избегайте также тех, кто с пафосом придаёт веб-разработке какую-то особую важность. Это не более чем ремесло. Ищите честных ремесленников.
Лучше работать с юридическим лицом
Если они разобрались с тем, как вести бухгалтерию, то мозгов и терпения на веб-сайт у них тем более хватит.
Одна лишь цена не гарантирует качество услуг
Я отбирал тех, кто казался мне профессионалом: разговаривал спокойно, отвечал вдумчиво, не запуская пластинку с рекламным текстом. Тех, кто относился к своей работе с пониманием того, что это просто рядовая услуга, которая должна быть выполнена качественно. В «шорт-лист» вышло 6 веб-студий. Их объединяло многое – например, в портфолио были качественные работы, которые, тем не менее, по своему функционалу не всегда пересекались с моим заданием. Однако все отличались в одном: в цене. Были те, кто просили на треть меньше самой высокой цены в «шорт-листе». А также те, кто просил в два раза меньше. Кого бы выбрали вы?
Я рассуждал так: все они для меня чёрный ящик. Каждый кажется профессионалом одного и того же уровня, поэтому с каждым из них я одинаково рискую. Какова цена риска? Стоимость услуги и, что хуже, упущенное время при срыве срока, которое можно было бы потратить на развитие. Увы, второе никогда заранее неизвестно, а первое было четко прописано в договоре. Я решил пойти по пути наименьшего риска.
Здесь нужно ответить на кажущиеся резонными замечания о том, что все мои проблемы идут исключительно из-за скупости, мол, выбери я команду, просившую больше денег, всех бед удалось бы избежать. Жаль, но я до сих пор так не думаю. Услуги веб-студии это не продукт в магазине, который можно повертеть, сравнить с соседним и оценить разницу в весе, габаритах и качестве сборки. Сколько условных килограмм веб-сайта вы получаете за крупную сумму? А сколько за в два раза меньше? Увы, столько же. Я задал вопрос самой «дешёвой» веб-студии из моего шорт листа в лоб – почему вы просите в два раза меньше своих конкурентов? Ответ «потому что мы не тратим деньги на аренду офиса, а программисты не из Москвы и работают удалённо» меня полностью устроил своей резонностью.
Что ж, выбор был сделан, и после финальной встречи мы условились подписать договор. Оглядываясь назад, я понимаю, что перед тем, как заключить с ними договор, я был бы очень рад наткнуться в сети на ещё ряд советов. Примерно таких:
Вы нанимаете работников, а не друзей
Довольно частная ошибка заказчика – желание задружиться с исполнителем. То же бывает и у исполнителя – на первой встрече менеджер веб-студии весело начал «Привет! Что у тебя за проект?». Я знал, что продуктивности это не добавит, поэтому вежливо остался на «вы». Этой же хладнокровности следовало придерживаться и в других вопросах.
Исполнителю не интересен ваш стартап
Встретившись с менеджерами веб-студии, я объяснил, что хочу сделать, как оно должно работать и главное — почему я это хочу сделать. Почему нужен AnyLanguage? Потому что в 21-м веке люди заслуживают комфорта в вопросе выполнения перевода. Мы можем быстро получать почти любые товары на дом, так почему нельзя получить на дом нотариально заверенный перевод? Зачем в 21-м веке нужна куча посредников в виде бюро переводов? Только ваше стремление изменить положение вещей и внутренняя уверенность в идее помогают двигать проект и не сойти с ума без выходных и личной жизни.
Не обольщайтесь, исполнитель из вашего рассказа запомнит только то, что вам нужен сайт. Качественный. Как и всем. Не рассчитывайте, что кто-то загорится вашей идеей. Тот, кто на заказ изготавливал братьям Райт поперечины каркаса для первого самолёта, делал просто поперечины каркаса, а не первый самолёт. Наблюдая за реализацией будьте готовы к самым невероятным нарушениями вашей концепции, причина которых проста: всем всё равно.
Сомневайтесь почаще при составлении договора
Вктарце: я допустил огромную ошибку, предполагая, что веб-студия умеет делать веб-сайты. Но вам следует думать иначе. Поймите, вы выбираете человека/команду, от которых зависит реализация вашей идеи. Что делать, если они подведут? Вопрос не риторический. Ответственность. Чем она выше, тем меньше вероятность срыва сроков. В моём случае штраф веб-студии за просрочку составлял… 50 рублей в день, но не более 50,000 рублей в общей сложности – сумма, которая бы накопилась через 2 с половиной года задержки. Как я допустил такую дыру в договоре? Очень просто: я полагал, что веб-студия умеет делать веб-сайты, и что пускай с неделей-двумя просрочки, но уж сайт-то мне сделают, поэтому для контроля оставил лишь один рычаг – поэтапную оплату работы.
Не повторяйте мою ошибку – умейте «включать говнюка» и подозревать худшее. Программисты могут не уметь программировать, риэлторы могут не уметь продавать квартиры, президент может не уметь управлять страной. За всё это должна быть прописана весомая ответственность в договоре. Помните, что договор придуман в первую очередь для того, чтобы обозначить потенциально возможные критические ситуации. Если исполнитель уверен, что справится с работой, возражений по поводу условия возврата всех уплаченных денег при срыве поэтапных сроков не должно последовать. Пользуйтесь этим.
Итак. Договор был заключён. Через неделю после этого у меня было готово идеально составленное ТЗ, которое ни разу не пришлось корректировать, и план работ, по которому мы двигались точностью час-в-час до самого финиша. Согласование дизайна прошло как по маслу. Через 2 месяца я получил не только идеально свёрстанный под мобильные платформы и старые версии Internet Explorer сайт, но также богатую возможностями панель администратора и тщательно оттестированный механизм заказа и оплаты.
Как бы ни так!
Как понять, что пора расчехлять микроменеджмент?
Довольно умное с виду слово «микроменеджмент» крайне вежливым образом скрывает за собой ад любого сотрудника. Это форма управления проектом, подразумевающая частую проверку промежуточного результата шефом в духе «Ну, как, готово? А сейчас? А теперь? Ну, сейчас-то готово?» или вмешательство в работу в духе «Нет, ну это никуда не годится – передвинь вот эту полосочку сюда, вот, видишь, сразу лучше стало». Микроменеджмент, распространённый в западных компаниях лет так 50 назад, на сегодняшний день считается крайне непродуктивной практикой. Если вкратце, такой подход не позволяет начальнику сосредоточиться на задачах более высокого уровня, а подчинённым раскрыть свой талант в самостоятельной работе и научиться думать, а не следовать жёсткой диктовке. Микроменеджмент чаще всего приводит к нервам и неэффективности – вы могли не раз слышать мнение, что «начальнику приходиться выполнять работу всего отдела». Этот подход почти никогда не бывает оправдан, а объективная необходимость его применения означает только одно – нерадивых сотрудников надо уволить и набрать новых.
Проще говоря, микроменеджмент – дерьмо. И, следовательно, подходит самым дерьмовым ситуациям. В одну из таких я и влип. Позвольте кристаллизовать этот опыт в набор выводов, которые я для себя сделал.
При детализации сроков, оценивайте не то, что вам сказали, а то, что забыли сказать
Мы условились, что работа будет завершена в течение 4 месяцев. Когда я попросил предоставить план с точностью до недели, я получил на первый взгляд довольно реалистичные сроки. Смущало одно: в разделе функционала не хватало графы «Интеграция с Яндекс.Кассой» –ключевой механизм, с помощью которого пользователи смогли бы оплачивать переводы. На мой вопрос «А это сколько по времени?» я получил ответ «Ну, мы потом прикрутим». «Прикрутим» растянулось на полтора месяца. К довольно важной функции подсчёта количества символов в документе для перевода отнеслись столь же поверхностно «Ну, думаем, недели хватит». Если исполнитель «думает», «прикручивает», «набрасывает» и т.д. – скорее всего, он не оценивает до конца сложность задачи. Поэтому смело умножайте названный им срок на число Pi – это не только звучит как что-то математически доказанное, но и почему-то всегда ближе к реальности, чем слова исполнителя.
Не обольщайтесь первым успехам
В моём случае всё действительно началось бодро. Я получил вполне сносно и почти без упущений составленное техническое задание, а затем одна за другой на меня начали сыпаться макеты страниц, и я только успевал утверждать их. Срок сдачи сайта приходился на 9 декабря, и ничто не предвещало беды. Кроме названия страны, в которой всё происходило – Россия. Только так можно объяснить то, что произошло далее. А именно – ничего. Целый месяц сочного наваристого ничего. Увы, именно в этот момент я сменил основную работу и тратил на новом месте порой до 14 часов в день – у меня не было возможности контролировать выполнение, и к тому же я был расслаблен хорошим темпом в начале.
Почему такое происходит? Разумеется, это объясняется в первую очередь некомпетентностью начальников веб-студий. Они настолько сфокусированы на получении новых заказов, что забывают или ленятся исследовать возможные подводные камни и обсуждать их с прикладными специалистами. В России плохо с культурой управления, поэтому можете считать, что начальника у проекта (если речь идёт о веб-студиях не из ТОП-10 с заоблачными ценами), скорее всего, нет. Следовательно, нет и команды, а есть просто набор специалистов. Поэтому, отдавая им свой проект под нож, вы рискуете несколько раз: сначала полагаетесь на дизайнера, затем – на программиста, где-то в промежутке – на администратора и тестировщика. Если сверху них нет эффективного контроля, ваш риск умножается на число таких людей: они могут медлить с работой, могут её игнорировать, у них могут быть другие приоритеты.
Если вы не разработчик, это не значит, что вы не можете контролировать разработку
Каскадная модель разработки, в которой осязаемый результат появлялся под конец срока, давно в прошлом. Современный цикл подразумевает наличие продукта в определённой степени готовности почти на всём своём протяжении. Если вам не могут в середине срока продемонстрировать сырую версию, то, скорее всего, никто ещё не приступал к работе. Если же вам показали сырую версию, не стесняйтесь её тестировать. Профессионал не делает разметку главной страницы тяп-ляп с мыслью «потом поправим», потому что понимает, что возвращаться назад к этапу, детали которого позабыты, себе же дороже. Если что-то появилось в сырой версии, оно с высокой вероятностью останется и финальной. Поэтому тестировать нужно при первой же возможности.
Я задал вопрос – как мне сообщать о найденных багах? «По электронной почте». Забудьте это. Забудьте блокнот (в смысле текстовый редактор) или, ещё хуже, блокнот (в смысле бумажный). Если вам не предлагают удобную систему трекинга ошибок, предложите её сами. Я воспользовался BugHerd’ом и этим обезопасил проект от путаницы в духе «Разве мы это ещё не устранили?». BugHerd – очень лёгкий баг-трекер, где требуется заполнить всего одно поле, чтобы создать баг. При этом автоматически делается скриншот области вокруг ошибочного элемента и запись о вашем web-клиенте – разработчик получает исчерпывающую информацию. За 3 месяца мой трекер пополнился более чем на 700 багов – смогло бы такое ужиться в почте или блокноте?
Следите за враньём – чем его больше, тем скорее потребуется ваше вмешательство
Когда я захотел посмотреть на промежуточный результат, разработчики слегли с неизвестной болезнью – все вместе и одновременно. Поломки бытовой техники сменяли поломки сервера, в одни дни кончались деньги на счету у интернет-провадера, а в другие «мы были в отъезде». Наконец, главный программист попал в больницу. Удивительно, в то же время я наблюдал радостные сообщение на facebook-страничке студии: «мы сдали сайт такой-то», «только посмотрите какой сайт мы сделали только что» и т.д.
Меня успокаивали, что ничего страшного в этом нет и всячески отрицали наличие проблемы. Последней каплей стало то, что в середине ноября мне пообещали, что, несмотря на форс-мажор, работа будет выполнена точно в срок – к 9 декабря. Ну, знаете ли, так даже по телевизору не врут.
Как понять, что у вас самый разгар кризиса
Если вам хочется ударить в лицо менеджера проекта – вдохните и выдохните три раза. Если желание не проходит, значит, момент настал. Он явно не справляется со своей работой, а вы злитесь от бессилия на это повлиять. Неделя до сдачи работы, а я даже не знаю, существуют ли в природе программисты, которые заняты моим сайтом. Всё, что у меня есть – макеты дизайна, худо-бедно свёрстанная главная страница без особого функционала и план работ по всему проекту, напоминающий больше инструкцию, как нарисовать сову. В этот момент я остановил себя от криков и угроз – очевидно, что с таким договором угрожать мне нечем, а покричать можно и на самого себя. Оставалось только одно – заменить менеджера. Собой.
Как пользоваться микроменеджментом
Можно упорно (и справедливо) задавать вопрос – почему управлять разработчиками должен человек, который как раз-таки заплатил деньги за то, чтобы ему всё сделали под ключ? Надо забыть про справедливость и понять: только это сдвинет проект с мёртвой точки. Передача управления прошла очень гладко: веб-студия явно хотела избавиться от ведения столь «кастомного» проекта и по сути дипломатично поставила меня нос-к-носу с разработчиками: нате, разбирайтесь теперь между собой. Более менеджеры веб-студии не могли ответить на вопрос про сроки: «Ну, вы же сами слышали, они обещали в конце января всё закончить». Единственный вопрос, в котором они оставались хоть сколько компетентными – выставление мне счета.
Итак, с начала декабря я познакомился (через Skype) с командой разработчиков и по сути в следующие 3 с половиной месяца стал их начальником. Я никогда не пользовался микроменеджментом ранее, поэтому регистрировал каждое движение, которое приводило к результату. Вот что в итоге позволило мне обеспечить максимальную эффективность.
Отключите эмоции и чувства. Особенно добрые
Более близкое знакомство показало, что, в целом, ребята-программисты были неплохими парнями. Со стороны я им мог только посочувствовать – их бросили на проект с разъярённым заказчиком за неделю до сдачи, и у них нет возможности сказать: «Привет! Мы только начинаем, поэтому нам нужно ещё как минимум 2 месяца». Им пришлось придумать нелепую байку, что полтора месяца они оттачивали модель данных, процессы передачи информации, базу данных и прочий бэк-енд сайта, а теперь остался, как выразился один из них, «тупой коддинг», который растянется, ну, максимум на неделю. Им постоянно приходилось давать сверхоптимистичные сроки, которые ни разу не соблюдались
Но будучи владельцем проекта, я мог воспринимать всю команду исключительно, как людей, которые гробят мою идею. Я запоминал все детали, каждое их обещание, ловил на противоречиях, заставлял объяснять каждый срыв сроков, с особой ревностью находил неточности в их работе и заваливал сотнями сообщений о багах.
Заставьте разработчиков прочитать ТЗ
На третью неделю плотной работы я понял, что один из программистов ТЗ вообще не читал, а второй в лучшем случае пробежался по разделам. Они интуитивно программировали макеты от дизайнера, считая, что всё понимают.
Спрашивайте прямые выдержки, ссылайтесь на пункты, задавайте по нему вопросы. Один мой знакомый вставил в середину ТЗ откровенную ересь – просто чтобы понять, дочитает ли кто-нибудь до этого места. Только делайте всё вежливо и без агрессии – работа всё равно выйдет за рамки ТЗ, и вам не нужно, чтобы жёсткое следование пунктам задания обернулось оружием против вас.Будьте готовы пропускать через себя ужасные ляпы
Грамотный тимлидер команды, которая делает сайт, избавляет заказчика от встречи с совершенным кошмаром: неработающими страницами, кривизной интерфейса, грамматическими ошибками и прочим. Но так как начальником был я, я видел каждый ляп, а порой не просто ляп, а полное отсутствие мысли. Некоторые баги были такими, что хотелось взять программиста за плечи, поднять над землёй и потрясти с криком «Да что у тебя там в голове вообще происходит?».
Перестаньте мыслить сроком проекта – думайте о сроках этапов.
Я чётко понимал, что, если знакомые с разработкой люди не смогли выдержать свои сроки, я тем более не смогу дать прогноз. Но вы можете понимать степень завершённости этапа и число этапов впереди. Возможно, получить всё, что вы хотели в начале, необязательно для запуска стартапа и проверки бизнес-идеи – не зацикливайтесь на реализации всех намеченных возможностей. Размышляйте концепцией Minimal Viable Product (MVP) – что действительно нужно? Чем можно пожертвовать ради ускорения? После 3-дневной пробуксовки с системой подсчёта символов в подгружаемых документах, я пожертвовал ею ради приближения к готовому MVP. Наверняка и вы найдёте, что урезать.
стировать всё равно придётся вам
Мне было очень важно иметь отлаженный, проработанный механизм приема платежей от клиентов и выплат переводчикам перед запуском сайта – нельзя было позволить «докручивать» финансовый механизм на живых пользователях. Когда имеешь дело с деньгами, аккуратности мало не бывает. Добиться её от разработчиков я не смог. Пришлось действовать по-другому – заваливать их багами. Потому что сами искать их они не хотели: «Рано! Пока и тестировать толком нечего. Завершим и протестируем» – я регулярно слышал это на созвонах. Поэтому упорно продолжал тестировать сам очередное обновление, выкладывал баги и отслеживал их устранение.
Чем чаще вы созваниваетесь, тем больше работы выполняется
Я заметил одну интересную вещь: частые созвоны вели к большей продуктивности. К примеру, если мы созванивались через два дня, а потом через четыре, я не замечал разницы в объёме работы, который получал за эти периоды. Бу Андерсон, нынешний руководитель АвтоВАЗа, сказал: «То, что в Европе делается за неделю, в России сделают за день. Потому что даже если дать русскому неделю, он всё равно всё сделает в последний день». Подтверждаю своим опытом.
Созваниваться было неприятно: это отнимало и время, и истощало эмоционально – слышать враньё, заранее невыполнимые сроки, при этом продолжать общаться вежливо на «вы». Очень хотелось пустить всё на самотёк, но один раз я уже допустил эту ошибку. В результате, мы созванивались по 4 раза в неделю, иногда даже пару раз в день – повод всегда был. А, главное, это был единственный действенный механизм получения результата.
ЗАКЛЮЧЕНИЕ
Несмотря на неприятный опыт, затраченные нервы и время, я смог добиться качественного сайта. Полгода назад устройство веб-приложения для меня было тёмным лесом – теперь же я знаю его составляющие, актуальные тренды в веб-разработке, а также могу дать пару советов из серии «как надо». И несколько десятков «как не надо». Я смог получить свой MVP, и это позволило сделать следующий шаг в развитии: ко мне присоединился IT-специалист, который взял на себя задачу технического совершенствования и развития сайта. Поэтому теперь я уже могу сменить роль менеджера веб-проекта на роли маркетолога, PR–менеджера, бухгалтера и многие другие. В стартапе работа всегда найдётся, и задача в том, чтобы в каждом новом её направлении самому подготовить базу, а затем найти специалиста, который займётся поддержкой и развитием вместо вас – я уверен, что после такого опыта, неожиданностей будет гораздо меньше.
Автор: KonstantinDa