Не стоит относиться к программистам, как к особенным людям

Почему я решил поделиться своим опытом с читателями Rusbase? Дело в том, что я прошел длинный путь в качестве владельца и руководителя строительной компании – от небольших муниципальных контрактов до серьезных авторских ремонтов элитных квартир под ключ. В итоге у меня появилась идея создать сервис Smetus, ориентированный на тех, кто делает ремонт. Первые две попытки запуска оказались провальными и стоили около 400 000 честно заработанных в полях рублей, а также полугода потерянного времени. Из этих двух поражений мы, команда проекта, вышли с высоко поднятой головой и даже не думали сдаваться: за время работы была сформирована более целостная картина структуры и ТЗ проекта в целом, а также был получен бесценный опыт. Именно его я и резюмирую сегодня в несколько важных пунктов:

1. О, боги…

В офлайн-бизнесе все слегка по-другому. Когда ты заходишь в другую сферу (в нашем случае – в онлайн), то вещи, которые ты не умеешь делать, кажутся поначалу сверхъестественным (например, написание кода). Но не стоит относиться к программистам, как каким-то особенным людям со сверхспособностями. В первую очередь это расслабляет их, а во вторую – всех остальных сотрудников. Так, в первые месяцы работы мы стали фиксировать колоссальное количество просроченных дедлайнов, на каждый из которых получали кучу непонятных обывателю, якобы адекватных, причин – почему дело не сделано и почему за это нельзя наказывать. В итоге для сохранения лояльности «инопланетянину» выдавали следующий дедлайн, при нарушении которого мы, по факту, наблюдали фиаско устоявшихся в компании правил: совершил «преступление» – получи наказание. Регламент и дисциплина должны быть едиными.

2. Твоя моя не понимать

Детально прорабатывайте не только ТЗ проекта, но и постановку каждой отдельной задачи. Первый наш провал был связан именно с этим. Если очень сильно утрировать, то наше первое ТЗ выглядело примерно так: «Требуется сделать онлайн-сервис для тех, кто делает ремонт, и чтобы там все считалось автоматически».

3. «Огласите весь список, пжлста!»

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

4. А можно мне номерок твоего бывшего?

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

5. «Вам какие огурцы – подлиннее или потолще? – Мне без разницы, мне на салат...»

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

6. MVP? Не, не слышал

По теме: Словарь предпринимателя – MVPНе пытайтесь решить сразу все задачи, это ведет к расфокусировке от основной ценности продукта и вносит неконтролируемый сумбур и хаос, особенно на начальных этапах формирования проекта, когда кроме вас никто еще не видит целостной картинки. Выделите MVP (минимальный работоспособный продукт) и ведите по нему приоритетный штурм. Остальные задачи следует обязательно зафиксировать и поставить в очередь с учетом иерархии их ценностей для клиента. Если бы мы вовремя не начали придерживаться этой стратегии, то навряд ли сейчас смогли запустить проект. До сих пор бы нас разрывало на части между множеством интересных дополнительных фичей.

7. «Лада седа-а-а-а-а-ан, ба-кла-жан!»

По теме: Как валидирование идей помогает запускать стартапы. Опыт #tcehДаже если вы сами являетесь своей же целевой аудиторией и вам нравится, как работает проект, и даже если он действительно решает ваши задачи – это еще не говорит о том, что он нужен рынку и надо бежать его масштабировать. Проведите сотни проблемных интервью в полях, поговорите с разными категориями своих потенциальных клиентов и только потом делайте соответствующие выводы.

Бог любит троицу, и уже с третьей попытки нашей команде удалось запустить Smetus. Сегодня MVP сервиса позволяет создавать мини-проекты помещений и рассчитывать автоматически все параметры, необходимые для производства ремонтных работ и расчета строительных материалов. На основе этих вычислений формируется ведомость объемов работ с возможностью ее ручной корректировки и выгрузки в формате Excel. Казалось бы, для B2C-сегмента, целевой аудитории, это уже вполне вменяемая ценность, но, как показали их многочисленные проблемные интервью с ЦА B2B, ее стоит увеличить для дальнейшей монетизации в сегменте. Чем, кстати, мы сейчас и занимаемся. Еще один факт, который выяснился в ходе прощупывания почвы для запуска: объем рынка в B2C-сегменте в России составляет 900 млрд рублей в год, а рынок B2B в десятки раз меньше. На первый взгляд, однозначно стоило бы фокусироваться на варианте с B2C, но при анализе полученной в диалогах информации выяснилось, что B2B готов платить гораздо больше и дает более выгодную картину в перспективе.