Работаю в ИТ с 2004 года. Пришёл осознанно в индустрию не за деньгами - по любви к технологиям и тишине, когда можно заставить машину делать нужные вещи. Начинал с настольных приложений на Delphi, бэкенд на Python, немного React. Сейчас Финтех.

История о том, как, работая тимлидом Python-команды, решился принять вызов на переход в сферу 1С и что из этого вышло.

Бойся своих желаний

Работал в Финтехе два года на позиции сеньора, потом - тимлида Python-команды. Команда из 5 человек. Сменились два CTO, и, так как Python не являлся основным стеком компании, я решил уйти в другую компанию. Пройдя собеседование, получив оффер, пришёл к боссу с заявлением. С одной стороны, манили перспективы, с другой – было желание получить более высокую зарплату на текущем месте, что, как я понимал, было невозможно, так как и статус, и зарплата были тем самым потолком, выше которого не прыгнешь. Босс (ещё тот психолог) сделал неожиданное предложение: хочешь большего - бери больше ответственности, бОльшую команду. И такой командой (а их 5  одной направленности) оказалась сфера 1С. На моё удивление по поводу  некомпетентности в 1С он  имел своё мнение: умелому и хорошему руководителю не так важна техническая составляющая, как другие навыки. “До какого возраста ты планируешь сидеть в разработке и заниматься сервисами, может, стоит двигаться вперёд и принимать решения о том, как должно выглядеть ИТ?”, - спросил он.  И я поддался на это “слабо”. Направление в тот момент представляло 4 команды разработки и техническая поддержка, всего 25 человек, пять тимлидов.

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

Лиха беда начало

Наследие  досталось сложное. С одной стороны,  отличные, знающие специалисты, с другой - положение направления в ИТ-контуре Компании. Люди - основа любой команды, и они были как бы демотивированы уходом предыдущего лидера и ИТ-директора (тоже 1-сник), но в то же время готовы   работать и поддерживать то, что строили вместе.

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

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

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

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

Вторая, тоже очень интересная книга, перекликается с книгой Уоткинса, но больше ориентирована на техническую стратегию. Рекомендую к прочтению эту книгу - «Технический директор. Эффективное техническое лидерство», автор - Уилл Ларсон.

За первый квартал хотелось выйти на технические и административные победы. Если с командой всё получалось более-менее неплохо, то оставались классические проблемы, которыми нужно заниматься системно. Главную менеджерскую проблему можно описать просто: «Это не моя проблема, другой команды, пусть смотрят они». С техническими успехами было сложнее. Мой приход пришёлся на рост Компании, и с самых первых дней возникли проблемы со сверками данных при закрытии периода, обновлением типовой, но достаточно сложной конфигурации с внешним вендором. И это уже налаживал последовательно.

Инсайты

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

Хочешь крутую, всё решающую команду - вкладывайся в обучение, вкладывайся в мотивацию. Будь для команды тем, с кем хочется работать. Создай атмосферу спокойствия, не надо доставать вопросами “ну что, когда?”, “ещё не готово?”. Для того, чтобы избежать необходимости поминутно спрашивать и жёстко контролировать, следует искать зрелых, опытных специалистов, которые знают, зачем пришли в эту Компанию, и готовы ко всякого рода сложностям. В моём случае, почти все были заряжены и готовы выкладываться. Оставалось дело за малым -  найти челленджи для команд, а тимлиды уже эти челленджи раздадут внутри.

Будучи как-то на TeamLead Conf, услышал, что тимлид не психолог и не родитель для сотрудника, а руководитель и коллега. Не получился в работе такой подход. Потребовались навыки психологии отношений, навыки коммуникаций. Не раз приходилось участвовать в личных проблемах коллег. И это не про то, чтобы быть родителем, это про участие и помощь. Помощь может быть разной: внимание, умение выслушать, дать разгрузку с задачами, смена графика работы. И, должен сказать, это ценится, находит отклик у сотрудников и сказывается на результатах работы. Слушай своих подчинённых, говори с ними – вот классный совет. 

Большим откровением был этап планирования квартальных затрат на направление. Это заблаговременный долгий процесс, где необходимо балансировать между премией, поездкой на конференцию и повышением заработной платы сотрудникам. Невозможно угодить всем, всегда будешь для кого-то недостаточно хорошим. У всех разная мотивация и разные цели. И вот здесь мне пришлось себя менять. Будучи разработчиком и работая теперь с бюджетом, хотелось дать нечто большее для сотрудников: премии, поездки на конференции, прием на работу  новых сотрудников под новые задачи. Но теперь я на другой стороне и одна из моих задач – экономить деньги Компании. Стратегически заглянуть в будущее, разобраться с нагрузкой, способностью производить ценности у команд и заложить это всё в бюджет. Да ещё потом и защитить бюджет перед своим боссом.

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

Что такое ответственность? Так часто можно услышать: бери ответственность на себя, делай больше. Ответственностью называют законченную задачу от начала до конца. Сначала – понять, полностью декомпозировать, найти классного исполнителя, донести исполнителю задачу, а затем часто или нечасто контролировать процесс. Я сам инженер и не люблю, когда вмешиваются в процесс. Итогом должна стать приёмка и, если можно так сказать, печать “ОТК”, что означает: результат проверен и годен. В моём случае ответственность — это понимание задачи, доведение до исполнителя, контроль и получение результата. Если результата нет, вина моя. В любом случае, и каждый недочёт – вычет из моего кредита доверия. Тут возникает интересная история: если результат хороший, то это достижение исполнителя, если результат не достигнут, виноват руководитель. А дальше уже сам ищи виновных и наказывай.

Да, наказание и премии. У руководителя должны быть инструменты поощрения и наказания. Без них не получится быть управленцем. С поощрением всегда просто: сделал задачу – получи награду. Но нет, и здесь есть нюансы. А за что награда, ведь ты получаешь уже свою заработную плату, это твоя обязанность приносить ценность Компании. Где эти сверхусилия, за которые полагается дополнительная плюшка?

Не всё так просто и с наказанием. Если наказывать за каждую ошибку, то не будет роста. Если не наказывать, а только журить, то прослывешь мягким и дисциплины не добьешься. Накажешь – станешь плохим. В этом случае хорошо быть новым руководителем в незнакомой команде, когда никого ещё не знаешь и рубишь направо - налево. Познакомившись с сотрудниками поближе (а  с сотрудниками, как я уже говорил, нужно  не просто разговаривать, но и слышать их), не сможешь уже просто так рубануть  сплеча по премии. В этой связи у меня хороший пример. Моим первым руководителем в далёком 2005 году была женщина. Так она всегда сама спрашивала: «Ну, что думаешь: как следует наказать за такой проступок (ошибку), который совершил второй/третий раз?». Ну и сам придумываешь. А что можно придумать? Лишаешь сам себя премии да плюшек. В то время ещё были офисные плюшки в виде отдельного кабинета да нового кресла. Сейчас уже такое не пройдёт.

Мои ошибки, на которых учился и учусь

Одной из первых ошибок было решение оставить технически крутого специалиста на позиции тимлида ключевой группы расчётов. Решение о его назначении было принято не мной, но я не увидел проблем в работе. Куча административной работы, управление командой, отчёты, технические сложности с закрытием бухгалтерского периода из-за ошибок сверок, сложностей с ростом Компании (объёмы данных) сделали своё дело, и тимлид ушёл. Деньги и просьбы остаться не помогли. Мне пришлось перехватить команду в административной части. Сложный период, когда, помимо общей работы с направлением, пришлось заниматься командой, связанной с бухгалтерией и операционным отделом. Не каждый может стать тимлидом. Тимлид — это не только высокая зарплата, но и бо́льшая ответственность и повседневная административная рутина, которая, как иногда кажется, отвлекает от масштабных, серьезных дел. Это встречи ради того, чтобы договориться, это контроль сроков за теми, кто не любит сроки, работа с вредными пользователями и программистами-звёздами, которые тоже, к слову сказать, не любят сроки и простые задачи.

Памятуя о том, как важно общаться и быть в курсе переживаний тимлида и сотрудников, я общался с лидами, прямыми подчинёнными (администраторы, архитектор, некоторые разработчики). Но снова попал в ловушку. Спустя полтора года другой тимлид решил уйти из рутины. Я поддержал его стремление к развитию, не препятствовал. Однако проблема возникла внезапно из-за внутренних перипетий команды: новый тимлид не хотел оставлять в команде “слегка чуждую” конфигурацию. Конфигурация, по правде говоря, была непрофильной для команды и достаточно сложной. Сложность, скорее всего, состояла из-за её влияния на регуляторные риски и бизнес-владельца. Вёл её один разработчик с самого начала работы в Компании. Будучи “отцом конфигурации”, на которой он вырос и только ею занимался, при внезапном уходе лида, захотел себе целую команду и роль лида, или, на крайний случай, эксперта с ростом заработной платы х2. Иначе уход, иначе развод. И вот здесь крылась моя вторая ошибка, в которой себя виню, - конфигурация была завязана на одном специалисте, дублёра не было, никто не знал, как все это устроено в подробностях. Конечно же, конфигурацию перехватил другой специалист, разобрался, но ценой немалых затрат. Месяцы инцидентов и удары по KPI команды. Урок из проблемы: все проекты, сервисы должны иметь дублёров, пусть не одинаково глубоко погруженных технически, но тех, кто в курсе, как оно работает.

При закрытии квартала мы столкнулись с техническими проблемами. Своими силами решить не получилось. Рекомендации от вендора не помогали либо были настолько оторванными от реальности (“добавьте 512 Гб памяти и всё будет нормально”), что лучше бы их не было. «Мы крутые, мы справимся» не сработало, нужно было признать это и идти к специалистам. Специалистом оказался Антон Дорошкевич с командой Инфософт в Новосибирске. Очень благодарны за решение проблемы в кратчайшие сроки. Оформили подписку на обслуживание в SLA. И ещё один инсайт для меня - надо повышать квалификацию внутри команды, у нас есть пробелы в техничке. Повышали через платные курсы, обучение. Ввели дополнительную штатную единицу администратора 1С со смещённым часовым поясом, чтобы покрывал время, когда администратор в Новосибирске отдыхает.

Ну и ещё одна интересная ошибка, самая-самая. Мы с лидом решили разделить одну большую конфигурацию, в которой очень много юридических лиц. Согласовали работы, проговорили с бизнесом и пошли делать. Но работа встала. Бизнес отказался работать по договоренности: нет времени, не моя забота, спросите у главного бухгалтера, узнайте у директора. Ну конечно же, типичная проблема, которую узнает любой профессиональный менеджер после вуза: не собрали рабочую группу, не выделили РП и не запустили проект в работу официально с промежуточным контролем сроков, и т.д, и т.п. Всё это приходит со временем. Читайте книги, слушайте коллег. Будут ошибки, но и придёт озарение.

Техническое

Самый частый вопрос от смежников и своих: полюбил ли я 1С, стал ли понимать язык?

В начале пути не было времени на погружение в язык. Вопросы общего характера покрывались знаниями из смежных языков программирования и подходами. Порой приходилось спускаться в глубину проблем, к примеру, наличие git для хранения кодовой базы, организация одновременной работы разработчиков с кодом, межсервисным взаимодействием. В определённый момент появилось желание узнать устройство языка. Начал смотреть известный курс на 20 дней. И меня бомбануло. Вещи, которые в настольных приложениях на Delphi делались в несколько часов, в 1С можно сделать мышкой и выбором из списка. Все стандартные операции по работе со списками и таблицами встроены в платформу и не требуют написания кода вообще. Технически интересно, но это как будто всё начинать сначала. Дойти до конца не получилось, хотя коллеги поддержали начинание и готовы были помочь. Внутри не смог убедить себя в надобности постижения азов программирования нового языка. Азы программирования не спасли бы, а понимание изнутри системных вещей требует базовых знаний. Оставил курс, но к затее периодически возвращаюсь. Более технически взрослые и состоявшиеся лиды и сотрудники приняли этот момент и не требуют погружения в технические дебри при объяснении. Достаточно раскрыть концепт.

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

Главная загадка для меня в этой большой вселенной 1С - приходящая в негодность конфигурация после обновления, иногда даже при обновлении в монопольном режиме. 

Продолжаю заниматься разработкой на Python в рабочее и свободное время. В рабочее - за счёт включения старой команды Python в состав 1С направления. Какая-то часть сервисов Python разрабатывалась для 1С, и теперь взаимодействие между командами стало проще. Свободное время выпадает не так часто, но появляется и это время наслаждения кодингом.

Текущая ситуация

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

Что делать с возникающими у сотрудников ошибками? Ошибки будут всегда. Без ошибок не получится вырасти. Хорошо, когда сотрудник учится на чужих, но обычно понимание приходит, когда наступает, и не раз, на собственные грабли. Если каждый раз наказывать за ошибки, будет страх их совершать, будут делать под копирку, используя известные стереотипы. Дать возможность ошибиться, даже если видишь, что делает не так, мне кажется полезным. Укоряю только за повторные ошибки, которые были проработаны и которые не назвать иначе, как глупостью. 

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

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

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

И ещё мне повезло с моим руководителем, который умеет делать предложения, от которых сложно отказаться. Босс немногословен при общении, но за каждым словом стоит решение проблемы, а разговор - как посещение конференции TeamLead Conf.

Заключение

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

 Рекомендую на чтение тимлидам в новым командах:

1. Ларсон Уилл. Технический директор. Эффективное техническое лидерство

2. Майкл Уоткинс. Первые 90 дней. Стратегии успеха для новых лидеров всех уровней