Нет ничего плохого в том, чтобы, открывая бизнес, стремится к совершенству. Но это не отменяет того факта, что необходимо разумно относиться к своим бюджетам и человеческим ресурсам. Особенно, если поджимают сроки. Так или иначе, вам придется срезать углы и экономить.

Но далеко не все осознают важность принципа адекватности решения поставленной задаче. Мне довелось поработать с такими людьми — превосходными специалистами и притом безнадежными идеалистами. Под катом я расскажу о своем опыте, объединив черты нескольких человек в один собирательный образ.

Знакомьтесь, Леонид

С Леонидом я впервые встретился лет 10 назад, когда только-только начинал свою карьеру. Он был на пару лет старше меня, получил превосходное высшее техническое образование и показался мне классным парнем. Когда бремя «работы на дядю» стало тяготить его, он принял решение открыть собственный бизнес в сходной нише. Формально мы были партнерами с равными долями, но при этом на правах основателя Леонид имел право вето и, надо сказать, регулярно им пользовался.

Мы неплохо ладили еще до начала совместной работы: общие увлечения, похожие взгляды на мир. Регулярно встречались за чашечкой чая, чтобы поболтать. Но стоило нам перейти к обсуждению рабочих моментов, как Леонид на глазах превращался из «своего парня» в тирана и деспота.

Ему ничего не стоило нагрузить меня тремя-четырьмя крупными задачами одновременно — лишь для того, чтобы через пару дней напоказ расстроиться, что я не выполнил одну из них. Он запросто мог потерять терпение и перебросить меня с одного проекта на другой, просто потому что «сроки на реализацию проекта A прошли, теперь мы делаем проект B». При этом степень готовности проекта А в расчет не бралась совершенно. Впрочем, обо всем по порядку.

Идеалист-босс и идеалист-исполнитель

Из вышесказанного вы могли сделать резонный вывод: Леонид — просто-напросто отвратительный управленец. И доля истины в этом, безусловно есть. Роль начальника он принял осознанно, руководствуясь своими представлениями о правильном и этичном бизнесе. При этом он был по-настоящему крутым разработчиком. Каждый раз, наблюдая за его работой, я поражался его умению найти элегантное и простое решение даже для самых сложных проблем. Иногда мы устраивали сеансы парного кодинга — и уже через 10-15 минут мой мозг отказывался понимать, что происходит на экране. Фактически, Леонид в соло мог работать за двоих, а мне отводилась скромная роль слушателя и корректора синтаксиса.

Однако всё то время, что мы работали вместе, Леонид тяготился ответственностью. Ему казалось, что если он хороший разработчик, он сможет качественно руководить командой и принимать взвешенные решения, основываясь на профессиональном опыте.

«Цивилизованный» подход к работе с людьми

Леонид искренне верил, что, будучи боссом, он обязан обеспечить для своих сотрудников наилучшие условия работы. «Европейский уровень» уверенности в завтрашнем дне.

Кое-чего ему действительно удалось добиться: зарплаты всеми правдами и неправдами, даже в тяжелые времена, выдавались аккуратно и в срок. Увольнения проходили спокойно и гладко — с полной оплатой отработанных на проекте часов, даже если после этого приходилось откатывать изменения за неделю-другую. Самые продуктивные сотрудники раз в полгода-год получали повышение.

Вместе с этим Леониду всегда было сложно поставить подчиненного на место. Вместо того, чтобы прямым текстом обозначить проблемы сотрудника, он юлил, выкручивался, доделывал работу за него и старался всячески «подсластить пилюлю», если дело доходило до прямой конфронтации. Леониду было проще высказаться мне, чем отругать недобросовестного сотрудника.

Стратегические решения

Леониду было тяжело принимать стратегические решения. Однажды он прямо признался мне в том, что не понимает, куда двигаться дальше. Почти все мои предложения он отвергал, поскольку они либо «принесут слишком мало денег, каплю в море», либо «я в это не верю, мы так делать не будем, и точка». Внутренний идеализм подсказывал ему, что серьезные компании не размениваются на мелочи вроде аутсорсинга или продажи ассетов.

По принципу «это плохая идея» отвергались, к примеру, предложения продавать готовые plug-and-play программные решения, разработанные для внутренних нужд стартапа, но потенциально нужные на рынке. Несмотря на наше шаткое положение, Леонид не рассматривал даже разработку чужих проектов на аутсорсе. Его сотрудники должны были разрабатывать только «его» продукты.

Однако это не мешало Леониду из-за боязни потерять сотрудника, работающего по почасовой оплате, в отсутствие объективно важных задач нагружать его всяким шлаком: например, написанием модулей для интернет-магазина, который по итогу так и не запустился. Деньги, вложенные в проект, тратились не по дням, а по часам (простите за каламбур), но к получению прибыли нас вовсе не приближали.

«Так должна работать хорошая компания»

Эти слова набили мне оскомину еще в первый год нашей совместной работы. Наша «хорошая» компания занималась выпуском ПО для мобильных платформ. Параллельно в разработке могло находиться по 2-3 проекта:

• Флагманский проект — в него вливалось до 80% средств, в нем были задействованы все сотрудники.

• «Запасной аэродром» — проект с гораздо меньшим приоритетом и более простым пайплайном разработки.

• Экспериментальный проект — MVP для тестирования гипотез без четких дедлайнов запуска и высоких требований к качеству.

Помимо проектов в активной разработке, у нас всегда было припасено несколько прошедших первичную проверку качества MVP на будущее. Какие-то из них доработать до полноценного продукта было слишком дорого. Какие-то требовали 100% внимания Леонида, поскольку только он сам мог довести их до ума.

Возвращаясь к принципу «хороших компаний» — из-за переизбытка проектов мы постоянно находились в поиске ненужных специалистов. Так, Леонид своими руками принял на работу и через месяц-другой за ненадобностью уволил: двоих проджект-менеджеров, тестировщика и дизайнера.

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

Проблема заключалась в том, что мы были стартапом, финансируемым из карманных средств. Мы могли позволить себе расходы в пределах $10-15 тыс. в год, но не более того. Львиную долю денег отъедали разработчики — даже при том, что мы платили далеко не самую конкурентную зарплату. Дизайн и маркетинг пожирали всё, что оставалось.

Я пытался втолковать Леониду, что тратить лишние деньги на проекты, которые могут так и не дойти до релиза только из желания подстраховаться или не потерять сотрудника, по меньшей мере неразумно. Но проще было остановить танк голыми руками, чем переубедить его.

По моим представлениям, «хорошей» можно назвать компанию, живущую по средствам и соблюдающую баланс между получением прибыли и комфортом сотрудников.

В целом же, мое видение было таким.

Чем меньше оборот компании, тем меньшим time-to-market должны обладать ее продукты. Нет смысла пилить проект-монстр, если есть немалый риск «лопнуть» до его релиза и первой прибыли.

Неприоритетные задачи (к примеру, сайт-визитка компании) должны решаться с минимальными вложениями, ровно достаточными для выполнения поставленной задачи. Нет смысла сразу же создавать мультиязычный сайт-магазин с поддержкой авторизации через все возможные соцсети, онлайн-покупками, если ни один проект в перспективе года-двух в нем не нуждается.

Леонид, даже осознавая справедливость этих тезисов, никак не мог смириться с ними. Даже если накануне мы обсуждали, что неразумно тратить силы на задачу N, через пару дней он возвращался с сотней доводов «за» её реализацию.

«Я займусь этим, когда освобожусь»

Как я уже писал выше, Леонид был первоклассным программистом. Он мог работать с чем угодно, от Python до языка ассемблера. Как исполнитель, он был бесценен. Однако совмещать роли начальника и core-разработчика у него совершенно не выходило.

Леонид умел писать отличный, оптимальный код. Но человеку со стороны разобраться в нем было не слишком просто. Какие-то модули Леонид создавал сам, с нуля, ввиду отсутствия готовых решений — и требовал у программистов пользоваться его наработками. В целом, отличная практика, если подкрепить её подробной документацией. Но документацию вести было некому — поэтому новых людей приходилось обучать в ручном режиме, путем регулярных многочасовых конф-коллов. В среднем, онбординг занимал у нас от двух недель до месяца — и это при сравнительно скромной кодовой базе.

Поскольку мы не могли себе позволить найм разработчиков рангом выше «крепкий middle», разработка самых ответственных частей приложений была залочена на Леонида.

Здесь важно сказать, что, помимо стартапа, и я, и Леонид параллельно работали в других компаниях и увольняться, не имея на руках успешного совместного бизнеса, не собирались.

Уже чувствуете, в чем проблема? Ни один релиз не мог состояться без привлечения Леонида как разработчика, product-owner’а и идеолога. В какой-то момент разработка того или иного проекта наглухо стопорилась, и со словами «у меня сейчас нет времени, давайте допилим пока проект N, с ним и Вася справится…» мы клали почти завершенный продукт в долгий ящик. Фактически замораживая вложенные деньги, теряя время и демотивируя участников команды, участвовавших в разработке. У людей создавался постоянный диссонанс между «давайте как можно скорее выпустим» и «у меня была очень загруженная неделя, поэтому я не знаю, когда смогу разлочить вас». Деньги тратились впустую, сотрудники неделями простаивали — или по инициативе Леонида занимались проектами, которым было не суждено появиться на свет.

До первых релизов мы добрались только через два года существования стартапа — и это были проекты, участие Леонида в которых было минимизировано.

«Нужно меньше фич, но нужно больше фич»

Фичекаттинг (отсечение лишнего функционала в угоду скорейшего выхода продукта), по моему мнению, важнейший навык бизнесмена — притом необязательно в ИТ-сфере. Если фича лежит за пределами core-функциональности и при этом требует значительных вложений, на старте стоит дважды подумать, прежде чем ее реализовывать.

К примеру, если у вас онлайн-магазин, не нужно сразу же включать поддержку всех платежных систем: достаточно одной, наиболее популярной. Это позволит быстро протестировать гипотезу и по итогам либо доработать функциональность, либо вовсе свернуть проект. Не нужно сразу же целиться на поддержку 100% фич лидеров рынка — но необходимо качественно реализовать свою, уникальную функциональность.

На еженедельных коллективных митингах Леонид требовал у нас отчета о проделанной работе — и отчитывался сам. В целом, полезная штука: каждый член команды знает, на какой стадии находится продукт и может наметить для себя стек работы. Но слишком часто с подачи Леонида эти собрания превращались в игру «кто придумает самую классную фичу, которую мы бросимся реализовывать, забив на дедлайны».

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

«Я начальник — ты дурак»

Долгое время наши дела шли довольно плохо: стартап не приносил деньги. Напротив, он всасывал их как пылесос. Из-за этого у нас обоих начались проблемы в семье. Прекрасные половины не понимали, зачем тратиться на то, что не приносит прибыль.

Отчасти в силу природного темперамента, отчасти из-за накопившегося стресса Леонид стал все чаще срываться на меня. Это выражалось в токсичных комментариях относительно моей компетентности и требованиях переписать всё так, как видит и хочет он. Не буду кривить душой — порой Леонид действительно был прав. Но зачастую я получал по шапке просто за то, что реализовал ту или иную фичу не так, как хотелось Леониду. Иной раз он мог в пух и прах раскритиковать даже утвержденный мной дизайн приложения — если тот не удовлетворял его (весьма аскетичному, «кодерскому») вкусу. Конечные сотрудники получали дистиллированный, мягкий фидбек, а яд доставался мне. Остынув, Леонид непременно извинялся. До прямых ссор ситуация ни разу не доходила — отчасти благодаря тому, что в какой-то момент я научился пропускать неконструктивную часть его комментариев мимо ушей.

Послесловие

Как я уже писал в начале статьи, Леонид — это собирательный образ. Вряд ли мне удалось бы сработаться с человеком, собравшим флеш рояль из всех перечисленных выше качеств.

Каждый из «прототипов» моего героя достиг успеха. С кем-то я продолжаю работать и по сей день, с кем-то поддерживаю дружеские отношения. Это действительно хорошие, достойные специалисты. Кому-то из них удалось преодолеть «болезни роста» из исполнителя в руководители. Кто-то решил вернуться в уютное кресло senior’а или тимлида.

Скорее всего, вы заметили в Леониде черты собственных коллег, партнеров или начальников. Это не хорошо и не плохо. Каждый из нас по-своему справляется с бременем руководства командой и принятием стратегических решений. Кому-то и вовсе не стоит вставать на этот торный путь. Лично я старался (и стараюсь до сих пор) вынести из общения и совместной работы с такими людьми максимум пользы: научиться не допускать их ошибки, принимать непростые решения — и подталкивать к ним своих будущих коллег-идеалистов.

Да, ужиться с такими людьми крайне непросто. Но если вам это удалось — держитесь. Вас ждет море уникального, полезного опыта.