4 ошибки, которые я допустил как CTO

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

На позицию CTO я пришёл не через стандартный путь “Developer -> Senior -> Team lead -> CTO”, а через гуманитарный вариант – “PM -> Senior PM -> CTO”. В этом были как свои плюсы, так и минусы, и трудно сказать, чего больше, но персональных челленджей хватало всегда и технический бекграунд часто спасал, однако, сейчас не об этом.

4. Вынужденные оценки

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

Эстимация новых лидов в аутсорсе – это то, от чего сильно меняется восприятие девелопмента и может поехать чердак. В первые месяцы я был уверен, что я-то уж точно никогда не допущу ошибок предыдущего технического директора, и точно не буду занижать оценки, чтобы взять все проекты. Первое время это удавалось, и уже через 2 квартала было четко видно, где проходит линия старого подхода оценивания, который мы назвали «да это 5 сек» и нового.

Очевидно, что с более пристальным подходом к оценкам увеличилось и время ожидания, и сами оценки. Стали появляться комплейны от сейлс-отдела, что мы затягиваем эстимейты и постоянно их завышаем. Но да ладно, с этим еще можно было бороться, объясняя важность этого этапа для всей последующей жизни потенциального проекта и для самой компании, которая уменьшает свои же риски. Аргументы из разряда «мы хотим сделать хорошо, потому нам нужно X часов на эту фичу» не работали вообще никогда в силу понятных причин – сейлам не нужно качественно, им нужно дешево. Но если с сейлс-отделом еще можно было бороться за право оценить лид хорошо, то практика, которая полностью убивала любую волю и желание что-то делать – это письмо высшего менеджмента в духе «Ребята, XYZ — это очень большой потенциальный партнершип, мы должны его зацепить!». Как правило, это означало, что свою оценку можно засунуть себе в ухо и провернуть там три раза по часовой стрелке, а потенциальный партнёр всё равно увидит то, что хочет показать топ-менеджмент. Никогда за всю мою практику ни к чему хорошему это не приводило, и «допродать потери» не удавалось. Самым вопиющим случаем был лид, когда оценку в более чем 3000 часов чистого дева пришлось ужимать до 1-й тысячи. Проект мы взяли, но потери по нему в итоге составили крупную для компании сумму, которая еще долго эхом аукалась всем.

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

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

3. Техническое отставание

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

За время работы в компании, не только в качестве СТО, у меня много раз была возможность сравнить нашу экосистему девелопмента и сторонние, в том числе компаний-конкурентов. Порой наше отставание было очень существенным и тут я говорю обо всем сразу: не использование новых тулов, которые ускоряли и упрощали разработку, не использование новых (или просто других) практик, отсутствие возможности постоянного обучения разработчика, отсутствие постоянного анализа рынка и так далее. Во многом это всё упиралось в бюджет и даже купить какой-то энтерпрайз софт, который нужен для каждодневного использования – это была проблема и цель, которой приходилось добиваться очень и очень настырно. Иногда удавалось доказать раку, что ему стоит-таки свистнуть на вершине горы, но случалось это настолько часто, насколько часто плотники воскресают и возносятся. Разумеется, подобное окружение отлично тренирует смекалку и выходы из разных ситуаций находились всегда, но это всё равно нездорово.

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

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

2. Job Description

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

Попыток же переписать и согласовать свой Job Description у меня было целых 3. Уже по их количеству можно понять, что процесс этот был нелегким, т.к. однажды увязнув в работе, которую ты делать не должен, вылезти из нее довольно трудно, ибо к твоему скафандру уже прилипло 30 тентаклей, которые не хотят тебя отпускать со дна. Всё это наложило свой отпечаток на сроки воплощения своих задумок и их непосредственную реализацию.

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

1. Кандидаты

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

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

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

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

Эпилог

По каждому из этих пунктов вполне реально написать по большой статье, но не сейчас. Многие ошибки, и не только эти, безусловно, были сделаны из-за отсутствия предыдущего подобного опыта, но это не делает их менее горькими. Отлично, что сейчас всё понятно и осознано — именно это и есть развитие – и хорошо, что это всё удалось конвертировать в опыт и новые навыки. Можно еще долго писать про то, что это всё взгляд не со стороны бизнеса, а желание остаться человеком, но это уже совсем друга история.

Автор: MennyCalavera

Источник ^[1]