На самом деле, ошибок было, безусловно, больше, но сейчас, спустя два года после начала работы в должности технического директора одного крупного мобильного аутсорсера, именно эти 4 кажутся мне главными.
На позицию CTO я пришёл не через стандартный путь “Developer -> Senior -> Team lead -> CTO”, а через гуманитарный вариант – “PM -> Senior PM -> CTO”. В этом были как свои плюсы, так и минусы, и трудно сказать, чего больше, но персональных вызовов хватало всегда и техническое прошлое часто спасало, однако, сейчас не об этом.
Помимо того, что я вынес в подзаголовок, сразу скажу, что первой ошибкой было всё-таки желание участвовать вообще во всех оценках, что отнимало у меня 60-70% времени поначалу. Постепенно я от этого отказался и стал заниматься только крупными лидами, оставив более мелкие оценки полностью на откуп тимлидам, которым научился доверять.
Оценка потенциальных проектов в аутсорсе – это то, от чего сильно меняется восприятие процесса разработки и может поехать чердак. В первые месяцы я был уверен, что я-то уж точно никогда не допущу ошибок предыдущего технического директора, и точно не буду занижать оценки, чтобы взять все проекты. Первое время это удавалось, и уже через 2 квартала было четко видно, где проходит граница старого подхода оценивания, который мы назвали «да это 5 сек» и нового.
Очевидно, что с более пристальным подходом к оценкам увеличилось и время ожидания, и сами оценки. Стали появляться жалобы от отдела продаж, что мы затягиваем сроки возвращения оценок и постоянно их завышаем. Но да ладно, с этим еще можно было бороться, объясняя важность этого этапа для всей последующей жизни потенциального проекта и для самой компании, которая уменьшает свои же риски. Аргументы из разряда «мы хотим сделать хорошо, потому нам нужно X часов на эту фичу» не работали вообще никогда в силу понятных причин – сейлам не нужно качественно, им нужно дешево. Но если с отделом продаж еще можно было бороться за право оценить проект хорошо, то практика, которая полностью убивала любую волю и желание что-то делать – это письмо высшего менеджмента в духе «Ребята, XYZ — это очень большой потенциальный партнер, мы должны его зацепить!». Как правило, это означало, что свою оценку можно засунуть себе в ухо и провернуть там три раза по часовой стрелке, а потенциальный партнёр всё равно увидит то, что хочет показать топ-менеджмент. Никогда, за всю мою практику, ни к чему хорошему это не приводило, и «допродать потери» не удавалось. Самым вопиющим случаем был тот, когда оценку в более чем 3000 часов пришлось ужимать до 1000. Проект мы выиграли, но потери по нему в итоге составили крупную для компании сумму, которая еще долго эхом аукалась всем.
Вторая особенность подобных случаев заключалась в том, что, как правило, подобные оценки нужно было подготовить за день-два, что, при постоянной перегрузке и овертаймах тимлидов, выливалось в дополнительные проблемы.
Ближе к текущему дню я научился отстаивать и обосновывать цифры в оценках перед любой публикой: от сейлов до высшего менеджмента, но то, что я так часто соглашался на авантюры типа «давайте подпишем за N часов, а потом еще N+700 допродадим» я считаю большой ошибкой.
Инерция в IT есть всегда, в аутсорсе в особенности, потому как отдельные технологии и компоненты порой очень быстро устаревают, но успевают за время своей жизни накопить приличный пласт зависящих от них людей, компаний и прочих компонент. И переключиться с одной технологии, или инструмента, на другой получается в основном на стыке проектов или их крупных фаз.
За время работы в компании, не только в качестве СТО, у меня много раз была возможность сравнить нашу экосистему разработки и сторонние, в том числе компаний-конкурентов. Порой наше отставание было очень существенным и тут я говорю обо всем сразу: не использование новых инструментов, которые ускоряли и упрощали разработку, не использование новых (или просто других) практик, отсутствие возможности постоянного обучения разработчика, отсутствие постоянного анализа рынка и так далее. Во многом это всё упиралось в бюджет и даже купить какой-то энтерпрайз софт, который нужен для каждодневного использования – это была проблема и цель, которой приходилось добиваться очень и очень настырно. Иногда удавалось доказать раку, что ему стоит-таки свистнуть на вершине горы, но случалось это настолько часто, насколько часто плотники воскресают и возносятся. Разумеется, подобное окружение отлично тренирует смекалку и выходы из разных ситуаций находились всегда, но это всё равно нездорово.
Когда удавалось, мы старались включать быстрое изучение новых инструментов, библиотек, технологий в продаваемые оценки, но было это нечасто и не регулярно. В итоге, со временем, это стало приводить к тому, что модные тренды и соответствующие запросы на оценки мы стали проигрывать, т.к. понятия не имели, как подобраться к той или иной теме. В качестве примера можно назвать проекты по дополненной реальности, которая для нас была черным ящиком очень долго.
Своей же ошибкой в данном случае я считаю допущение подобной ситуации в целом, когда технологический уровень компании растёт неконтролируемыми рывками, а не плавно. Хотя, стоит признать, что в условиях ограниченного свободного времени и бюджета я и сейчас вижу лишь пару возможностей эту ситуацию исправить, об одной из которых я напишу ниже.
Самый личный пункт, который коснулся меня напрямую, но дабы не лить слёзы, постараюсь описать его кратко. Любой перечень работ должен быть оговорён заранее – это стандарт, но часто мы пренебрегаем этим в разрезе собственной позиции. Такую ошибку допустил и я изначально, когда переходил в новую должность. В итоге я стал ответственным за всё сразу, начиная от закупок техники, что нормально, до совсем диких вещей, вроде выполнения плана по прибыльности и попыток реорганизации работы сейл-отдела. И, разумеется, часть тасков проваливалась, т.к. я был занят чем-то другим.
Попыток же переписать и согласовать свой Job Description у меня было целых 3. Уже по их количеству можно понять, что процесс этот был нелегким, т.к. однажды увязнув в работе, которую ты делать не должен, вылезти из нее довольно трудно, ибо к твоему скафандру уже прилипло 30 тентаклей, которые не хотят тебя отпускать со дна. Всё это наложило свой отпечаток на сроки воплощения своих же задумок и их непосредственную реализацию.
Это немалая ошибка, т.к. времени, убитого на таски, которыми технический директор заниматься не должен, и не должен о них даже думать, было очень много.
Сердечная боль, пожалуй, любого человека, которому приходится собеседовать большое количество людей – это часто невозможность брать тех кандидатов, которые тебе действительно понравились и постоянная борьба с высшим руководством за то, чтобы не превращать компанию в плантацию джуниоров. Как правило, дело здесь в деньгах и условиях. Ни в коей мере я не хочу сказать, что приходилось брать на работу плохих разработчиков, нет. Наоборот, отбор у нас был более чем жесткий всегда и я всегда понимал, что может принести с собой senior или просто хороший дорогой кандидат. Это не только опыт, но и знакомства, новая экспертиза, новые идеи, критический взгляд и много другого. Однако всегда вопрос стоимости приобретения подобного игрока был главенствующим.
Очень много раз мне приходилось откладывать в сторону резюме кандидатов, с которыми я только что беседовал, лишь по той причине, что каждой позиции был назначен финансовый потолок. Это стандартная практика, но своей ошибкой я считаю то, что я соглашался с таким подходом и поздно научился обосновывать значимость того или иного кандидата с точки зрения финансов и экспертиз. И тут мы говорим именно об обоснованно дорогих разработчиках.
Произошло это тогда, когда я уехал организовывать новый офис разработки. Именно когда я был единственным, кто принимал решения о найме людей, я мог, скажем, в 8-ми случаях из 10 брать именно тех, кто нравился больше всего. Пришлось пройти через много споров и разговоров о завышенных ЗП кандидатов с советом директоров, но оно того стоило и люди, которых мне посчастливилось нанять дали просто отличный результат, которого не ожидал никто. Именно тогда, имея на руках результаты работы этих людей и целую пачку их идей и предложений, я понял, как именно следует обосновывать желание взять того или иного кандидата — цифрами.
Немаловажным пунктом здесь будет еще и то, что найм дорогих игроков – это как раз один из вариантов технологического роста компании, ведь именно опытные девелоперы могут познакомить младших коллег с чем-то новым «не отходя от кассы» и разбавить образовавшийся застой. Именно так мы решили вопрос с экспертизой по дополненной реальности — наняв человека с большим опытом в этой области помимо всего прочего.
По каждому из этих пунктов вполне реально написать по большой статье, но не сейчас. Многие ошибки, и не только эти, безусловно, были сделаны из-за отсутствия предыдущего подобного опыта, но это не делает их менее горькими. Отлично, что сейчас всё понятно и осознано — именно это и есть развитие – и хорошо, что это всё удалось конвертировать в опыт и новые навыки. Можно еще долго писать про то, что это всё взгляд не со стороны бизнеса, а желание остаться человеком, но это уже совсем друга история.
На позицию CTO я пришёл не через стандартный путь “Developer -> Senior -> Team lead -> CTO”, а через гуманитарный вариант – “PM -> Senior PM -> CTO”. В этом были как свои плюсы, так и минусы, и трудно сказать, чего больше, но персональных вызовов хватало всегда и техническое прошлое часто спасало, однако, сейчас не об этом.
4. Вынужденные оценки
Помимо того, что я вынес в подзаголовок, сразу скажу, что первой ошибкой было всё-таки желание участвовать вообще во всех оценках, что отнимало у меня 60-70% времени поначалу. Постепенно я от этого отказался и стал заниматься только крупными лидами, оставив более мелкие оценки полностью на откуп тимлидам, которым научился доверять.
Оценка потенциальных проектов в аутсорсе – это то, от чего сильно меняется восприятие процесса разработки и может поехать чердак. В первые месяцы я был уверен, что я-то уж точно никогда не допущу ошибок предыдущего технического директора, и точно не буду занижать оценки, чтобы взять все проекты. Первое время это удавалось, и уже через 2 квартала было четко видно, где проходит граница старого подхода оценивания, который мы назвали «да это 5 сек» и нового.
Очевидно, что с более пристальным подходом к оценкам увеличилось и время ожидания, и сами оценки. Стали появляться жалобы от отдела продаж, что мы затягиваем сроки возвращения оценок и постоянно их завышаем. Но да ладно, с этим еще можно было бороться, объясняя важность этого этапа для всей последующей жизни потенциального проекта и для самой компании, которая уменьшает свои же риски. Аргументы из разряда «мы хотим сделать хорошо, потому нам нужно X часов на эту фичу» не работали вообще никогда в силу понятных причин – сейлам не нужно качественно, им нужно дешево. Но если с отделом продаж еще можно было бороться за право оценить проект хорошо, то практика, которая полностью убивала любую волю и желание что-то делать – это письмо высшего менеджмента в духе «Ребята, XYZ — это очень большой потенциальный партнер, мы должны его зацепить!». Как правило, это означало, что свою оценку можно засунуть себе в ухо и провернуть там три раза по часовой стрелке, а потенциальный партнёр всё равно увидит то, что хочет показать топ-менеджмент. Никогда, за всю мою практику, ни к чему хорошему это не приводило, и «допродать потери» не удавалось. Самым вопиющим случаем был тот, когда оценку в более чем 3000 часов пришлось ужимать до 1000. Проект мы выиграли, но потери по нему в итоге составили крупную для компании сумму, которая еще долго эхом аукалась всем.
Вторая особенность подобных случаев заключалась в том, что, как правило, подобные оценки нужно было подготовить за день-два, что, при постоянной перегрузке и овертаймах тимлидов, выливалось в дополнительные проблемы.
Ближе к текущему дню я научился отстаивать и обосновывать цифры в оценках перед любой публикой: от сейлов до высшего менеджмента, но то, что я так часто соглашался на авантюры типа «давайте подпишем за N часов, а потом еще N+700 допродадим» я считаю большой ошибкой.
3. Техническое отставание
Инерция в IT есть всегда, в аутсорсе в особенности, потому как отдельные технологии и компоненты порой очень быстро устаревают, но успевают за время своей жизни накопить приличный пласт зависящих от них людей, компаний и прочих компонент. И переключиться с одной технологии, или инструмента, на другой получается в основном на стыке проектов или их крупных фаз.
За время работы в компании, не только в качестве СТО, у меня много раз была возможность сравнить нашу экосистему разработки и сторонние, в том числе компаний-конкурентов. Порой наше отставание было очень существенным и тут я говорю обо всем сразу: не использование новых инструментов, которые ускоряли и упрощали разработку, не использование новых (или просто других) практик, отсутствие возможности постоянного обучения разработчика, отсутствие постоянного анализа рынка и так далее. Во многом это всё упиралось в бюджет и даже купить какой-то энтерпрайз софт, который нужен для каждодневного использования – это была проблема и цель, которой приходилось добиваться очень и очень настырно. Иногда удавалось доказать раку, что ему стоит-таки свистнуть на вершине горы, но случалось это настолько часто, насколько часто плотники воскресают и возносятся. Разумеется, подобное окружение отлично тренирует смекалку и выходы из разных ситуаций находились всегда, но это всё равно нездорово.
Когда удавалось, мы старались включать быстрое изучение новых инструментов, библиотек, технологий в продаваемые оценки, но было это нечасто и не регулярно. В итоге, со временем, это стало приводить к тому, что модные тренды и соответствующие запросы на оценки мы стали проигрывать, т.к. понятия не имели, как подобраться к той или иной теме. В качестве примера можно назвать проекты по дополненной реальности, которая для нас была черным ящиком очень долго.
Своей же ошибкой в данном случае я считаю допущение подобной ситуации в целом, когда технологический уровень компании растёт неконтролируемыми рывками, а не плавно. Хотя, стоит признать, что в условиях ограниченного свободного времени и бюджета я и сейчас вижу лишь пару возможностей эту ситуацию исправить, об одной из которых я напишу ниже.
2. Job Description
Самый личный пункт, который коснулся меня напрямую, но дабы не лить слёзы, постараюсь описать его кратко. Любой перечень работ должен быть оговорён заранее – это стандарт, но часто мы пренебрегаем этим в разрезе собственной позиции. Такую ошибку допустил и я изначально, когда переходил в новую должность. В итоге я стал ответственным за всё сразу, начиная от закупок техники, что нормально, до совсем диких вещей, вроде выполнения плана по прибыльности и попыток реорганизации работы сейл-отдела. И, разумеется, часть тасков проваливалась, т.к. я был занят чем-то другим.
Попыток же переписать и согласовать свой Job Description у меня было целых 3. Уже по их количеству можно понять, что процесс этот был нелегким, т.к. однажды увязнув в работе, которую ты делать не должен, вылезти из нее довольно трудно, ибо к твоему скафандру уже прилипло 30 тентаклей, которые не хотят тебя отпускать со дна. Всё это наложило свой отпечаток на сроки воплощения своих же задумок и их непосредственную реализацию.
Это немалая ошибка, т.к. времени, убитого на таски, которыми технический директор заниматься не должен, и не должен о них даже думать, было очень много.
1. Кандидаты
Сердечная боль, пожалуй, любого человека, которому приходится собеседовать большое количество людей – это часто невозможность брать тех кандидатов, которые тебе действительно понравились и постоянная борьба с высшим руководством за то, чтобы не превращать компанию в плантацию джуниоров. Как правило, дело здесь в деньгах и условиях. Ни в коей мере я не хочу сказать, что приходилось брать на работу плохих разработчиков, нет. Наоборот, отбор у нас был более чем жесткий всегда и я всегда понимал, что может принести с собой senior или просто хороший дорогой кандидат. Это не только опыт, но и знакомства, новая экспертиза, новые идеи, критический взгляд и много другого. Однако всегда вопрос стоимости приобретения подобного игрока был главенствующим.
Очень много раз мне приходилось откладывать в сторону резюме кандидатов, с которыми я только что беседовал, лишь по той причине, что каждой позиции был назначен финансовый потолок. Это стандартная практика, но своей ошибкой я считаю то, что я соглашался с таким подходом и поздно научился обосновывать значимость того или иного кандидата с точки зрения финансов и экспертиз. И тут мы говорим именно об обоснованно дорогих разработчиках.
Произошло это тогда, когда я уехал организовывать новый офис разработки. Именно когда я был единственным, кто принимал решения о найме людей, я мог, скажем, в 8-ми случаях из 10 брать именно тех, кто нравился больше всего. Пришлось пройти через много споров и разговоров о завышенных ЗП кандидатов с советом директоров, но оно того стоило и люди, которых мне посчастливилось нанять дали просто отличный результат, которого не ожидал никто. Именно тогда, имея на руках результаты работы этих людей и целую пачку их идей и предложений, я понял, как именно следует обосновывать желание взять того или иного кандидата — цифрами.
Немаловажным пунктом здесь будет еще и то, что найм дорогих игроков – это как раз один из вариантов технологического роста компании, ведь именно опытные девелоперы могут познакомить младших коллег с чем-то новым «не отходя от кассы» и разбавить образовавшийся застой. Именно так мы решили вопрос с экспертизой по дополненной реальности — наняв человека с большим опытом в этой области помимо всего прочего.
Эпилог
По каждому из этих пунктов вполне реально написать по большой статье, но не сейчас. Многие ошибки, и не только эти, безусловно, были сделаны из-за отсутствия предыдущего подобного опыта, но это не делает их менее горькими. Отлично, что сейчас всё понятно и осознано — именно это и есть развитие – и хорошо, что это всё удалось конвертировать в опыт и новые навыки. Можно еще долго писать про то, что это всё взгляд не со стороны бизнеса, а желание остаться человеком, но это уже совсем друга история.
