«Собянин приедет завтра, срочно доделываем»: ИТ-компания рассказывает о своих провалах и выводах

Все компании ошибаются. Многие проходят через похожие проблемы и совершают примерно одинаковые ошибки. В том числе ИТ-компании. Другой вопрос — какие выводы делает каждая из них. Сергей Вардомацкий, CEO компании HQSoftware, поделился промахами и провалами своей команды и рассказал о тех уроках, которые компания вынесла из них, и правилах, которые в итоге они для себя сформулировали.

— За все время работы у нас, как и у любой другой компании, было много ошибок. Но мы сумели признать их, проанализировать и сделать свои выводы.

Приведу два кейса, которые помогли нам в этом. А также поделюсь принципами нашей работы, которыми мы теперь руководствуемся.

Наши провальные проекты

О самом провальном проекте: мы работали с частью проекта «Госуслуги» России, лет 8 назад. В процессе были определенные проблемы:

• Мы оказались в ситуации, когда между нами и даже промежуточным заказчиком есть посредники, которые изолировали нас от коммуникации с клиентом и вносили в нее хаос. Мы никак не могли повлиять на процесс работы, так как были отделены от принятия решений.
• Процесс работы был крайне хаотичным. Заказчик общался с конечным клиентом, приносил оттуда требования со словами «сделать нужно вчера» или «Собянин приедет завтра на демо», и так восемь дней подряд. Отказаться уже нельзя — заказчик не оплатит счет за два месяца, а посредник, который по договоренности отвечал за эти риски, обязательств выполнять не мог.

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

Все закончилось провалом, нам не заплатили. Проект был очень большим для нас в тот момент. Долги мы раздавали долго, компания не закрылась только «волевым решением».

Какие выводы мы сделали из этого кейса и чему научились?

1. Не работать через посредника. Мы будем рады заплатить комиссию за клиента, но если мы отвечаем за проект, то мы им и управляем.

2. При попытках манипуляций и шантажа — не поддаваться. Заранее понятно, что проект провалится, значит, клиента уже и так нет, и потерять его не страшно.

3. Правильно построенный процесс разработки — основная часть заботы о команде. С хорошим менеджером приятно работать, даже если технологии не самые интересные. Команда ощущает себя защищенной, понятны ожидания, есть реалистичные дедлайны.

Еще один кейс. И он тоже доказывает важность наличия хорошего менеджмента. На одном из проектов, который был интересен нам настолько, что мы попросили долю в этом стартапе, вышло вот что. Мы делали много разных демо и концептов крупной командой, потратили много денег и времени. И вроде бы все шло хорошо, результат работы можно было показать на выставках, потенциальным инвесторам. Но по факту сам продукт не строился. И проблема была в нескольких аспектах.

Главный из них — стартаперы просили, и мы делали красивую картинку, чтобы продавать. Вместо того чтобы сосредоточиться на технологии.

Так мы накопили технический долг. Когда начали появляться пользователи, все поняли, что отдавать им нечего и пользоваться нечем.

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

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

Эти четыре месяца мы внимательно копали в сторону всяких нетривиальных случаев. Что, если пользователь пойдет куда-то не туда? И много других «если». Важно было убедить не только аналитиков, а именно команду действительно пользоваться продуктом. Это было одним из важнейших шагов. И здесь прием «нельзя верить клиенту» в хорошем смысле сработал как нельзя лучше. Главный вывод, который мы сделали в этом кейсе: клиент может ошибаться, но к нам он пришел именно за умением решить его задачу и исправить его ошибки.

Наши правила работы

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

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

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

3. Отказ от заранее провальных проектов. Мы считаем, что у нас сильная команда менеджеров по продажам.

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

А вот провалы демотивируют команду: мы рискуем потерять людей, которые и являются основным капиталом любого бизнеса, не только ИТ.

4. Нужно стремиться быть на острие технологий. Это хорошо и для продаж, и для развития команды. Конечно, есть legacy systems. Но важен баланс. Поясню.

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

Например, никто не любит работать со старыми технологиями. Но от них не избавишься. Программисты хотят работать с самым новым и самым модным, но этого нельзя ожидать во всех случаях. Обычно 80% работы — это рутина, и 20% — новая крутотень, но при этом не всегда технически зрелая. Поэтому часто, когда мы получаем крупного клиента, он может быть не готов к самому новому и модному. Ведь это самое непонятное и ненадежное, а еще ему важно понимать, как он будет это поддерживать, если аутсорсера не станет. Из этого же вытекает следующее правило. 

5. Мы стараемся сделать так, чтобы старье нас не съедало. У нас есть отличный пример. Проект — онлайн-академия одного из крупнейших автопроизводителей, мультинациональный проект, но это 20 сайтов на Joomla, со стороны разработчика. Клиент очень стабильный: надежный, понятный и предсказуемый, ему приятно с нами работать долго. Казалось бы, мы несем в мир радость, учим безопасному вождению и даже можем измерить, сколько жизней мы спасли за счет того, что у нас есть этот проект, это очень круто. Но стоит вспомнить, что это 20 сайтов на Joomla, как энтузиазм угасает… Конечно, нам хотелось бы работать с более свежими технологиями.

Проекту больше 8 лет, мы стремились избавиться от технического долга и рудиментов, но иногда от заказчика требования приходят менее скоординированно, чем хотелось бы разработчикам. Перейти с Joomla нельзя — корпоративный стандарт. И мы отлично понимаем, что разработчикам это не нравится, много зависимостей и головной боли. Поэтому мы для себя приняли и утвердили с клиентом такую политику — этот проект у нас носит роль своеобразной школы:

• Мы его используем, чтобы брать в команду людей, которые знают Joomla и ничего кроме. Например, людей из веб-студий, которые хотят стать разработчиками. Показывать им нормальные процессы разработки и давать время подтянуть технические знания.
• У нас есть правило, о котором знает каждый: на этом проекте человек работает от года до полутора — и все.

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

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

6. Команда — самая большая ценность. Мы поэтому о ней заботимся и организовываем рабочий процесс таким образом, чтобы человек не закисал, переключался на что-то, чего не делал раньше. И таким образом удовлетворяем способность и желание работать с новыми «фишечками». Плюс мы за счет этого видим людей, которые хотят развиваться, которым интересно пробовать что-то. Если не интересно, человек может заниматься этим проектом — его право, но это редкий случай. Либо нам не по пути, человек не вписывается в нашу культуру, и мы расходимся.

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