Когда меня назначили на должность тимлида, я уже отработал в компании в качестве программиста в течение 8 лет. Так что мне не пришлось знакомиться с коллективом и существующими проблемами; все их я и так знал. Однако моё назначение совпало с всплеском активности компании по работе с новыми проектами и по модернизации старых. Из-за этого пришлось сильно напрягаться в течение всех 6 месяцев моей работы.
Мой предшественник проделал большую работу по внесению порядка в царивший в компании до этого хаос разработки, но мне пришлось сделать ещё больше и в короткие сроки. Связано это не с моей гигантской работоспособностью, а просто с требованиями жизни.
В первую очередь мне пришлось создавать документацию по разработке почти с нуля.
В компании постоянно возникали проблемы с тем, что трудно было найти исходники тех или иных проектов (они были "закопаны" глубоко в недрах Git/TFS, а самые древние вообще лежали в файловой системе). Хранящиеся исходники могли быть не совсем актуальными (то есть отгруженный продукт мог быть создан с исходников, которые модифицировал уже уволившийся человек. Он их, разумеется, не сохранил). Найденные исходники могли с ходу не компилироваться. А для работы могли требоваться нигде не документированные компоненты.
Поскольку пул проектов компании был довольно велик, а не со всеми проектами за все время работы мне пришлось иметь дело самому, всю информацию об этих проектах было невозможно удержать в голове. Именно поэтому я и начал свою деятельность с составления реестра проектов. Параллельно с этим никто не снимал с меня обязанностей программиста: мне приходилось работать на фронте, на котором я действовал до своего повышения. В связи с этим работа шла в условиях довольно высокой нагрузки. Но поставленная задача упорядочить этот хаос была мне интересна, и я этой нагрузки не замечал.
У меня в подчинении было 6 разработчиков, и на тот момент этого не хватало. Буквально за полгода до этого из компании ушло два программиста, и часть проектов просто подвисла. А начать продвигать их мы могли в любое время. В связи с этим сразу же было открыто две вакансии программистов, которые мы закрыли в течение двух месяцев.
Отсутствие собственного времени на обучение новых программистов, да и просто необходимость как можно быстрее включить их в работу и побудила меня создать Landing Page для разработчиков нашей компании. В идеале программист садился за своё рабочее место, я подходил к нему и открывал единственную страницу браузера. После чего он переходил по ссылкам и спустя какое-то короткое время уже начинал работать, причём по правилам, которые на тот момент уже внедрялись в компании. Так и получилось: каждый из двух новоприбывших программистов уже на третий день своей работы приступил к решению реальных задач. До этого времени процесс ввода программистов в строй занимал несколько недель.
Landing Page описывала, где взять софт, необходимый для работы; как сделать те или иные базовые задачи (например, Cherry-Pick в Git или миграции в Entity Framework), а также общую архитектуру и методологию разработки нашей команды.
Жизнь подсказывала и прочие необходимые доработки в Confluence. Продукты страдали из-за низкого качества кода, в релиз часто уходили непротестированные изменения. Поэтому я стал описывать правила оформления кода, вводить раздельные ветки разработки и Code Review. Последнее, к сожалению, я не успел внедрить целиком, но вся технологическая база была подготовлена, необходимые изменения в JIR'у были внесены и регламенты написаны.
Также я консультировался со своими коллегами и знакомыми в целях быстрого получения полезного опыта. Мне подсказали проводить беседы тет-а-тет с подчинёнными, слушать их пожелания, стараться обеспечить им комфортные условия работы.
Тут и было самое интересное. Программисты - все люди разные. К каждому нужен свой подход. У каждого свой характер, свой технологический стек, свои предпочтения. У кого-то высокая работоспособность, кто-то ленится. Приходилось внимательно прислушиваться к пожеланиям, но, разумеется, далеко не всегда их можно было удовлетворить - мы же в первую очередь решали производственную задачу.
Здесь можно отметить одно из самых проблемных мест моего управления: возникали ситуации, когда я был загнан как лошадь (в том числе, в программировании), а у кого-то из моих подчинённых не хватало работы. Я стал учиться больше делегировать и доверять, это крайне важно. Код, который приходит от программиста, может привести в ужас, но такова жизнь. Для удержания кода в адекватных рамках и надо создавать требования к архитектуре и исходному коду. Потом на них можно смело ссылаться. Ну и про автоматизированное тестирование не надо забывать.
Плюс проблема была ещё и в том, что изначально на мне висело очень много проектов. Когда я выступал в роли программиста, я не задумывался об их описании - это была не моя забота. После повышения мне, как я уже сказал, пришлось срочно готовить описания всех проектов компании. Как только я заканчивал описание того или иного компонента, я сразу же назначал на него ответственным одного из моих подчинённых. В конце концов, это помогло: я раздал всё и занялся исключительно технологической, архитектурной и управленческой работой. Но, разумеется, и консультировать по исходному коду этих проектов приходилось постоянно.
Программисты хотели технологической модернизации нашего кода. И там, где позволяли технические требования, мы стали внедрять новые технологии: .NET Framework 4.6.1, Web API. Стали смотреть в сторону .NET Core.
Повышение качества кода потребовало и написания юнит-тестов. Мы стали внедрять TDD на отдельно взятом проекте, стали обучать тестировщиков писать юнит-тесты и готовить нашу архитектуру к тому, чтобы эти тесты на ней можно было выполнять.
Важной задачей было и улучшение качества сопровождения кода, для чего требовался рефакторинг. Эта задача обычно не ценится высоко руководством - ведь функциональность при этом не расширяется. Это можно парировать ростом надёжности и производительности, для чего и нужны метрики качества. Обычно рефакторинг выполняется в фоновом режиме в привязке к некоторой другой задаче. Разумеется, иногда требуется крупный рефакторинг, и на это выделяется отдельный программист.
Для грамотного рефакторинга нужна корректно поставленная цель. Такой целью и являлись требования к архитектуре: необходимо разбить сложный компонент на иерархию слабо связанных модулей, что открывает широкий простор для юнит-тестирования. Архитектура также была описана в нашей системе документирования.
В рамках улучшения условий работы мы произвели перестановку в комнате, выселили шумных коллег в другое помещение, а программистов из других комнат переселив к нам. В итоге образовалась тихая и уютная комната программистов.
В целях повышения качества разработки были опробованы элементы SCRUM и итеративного программирования. Мы внедрили на проекте недельные спринты. В пятницу в спринт накидывались задачи. Список задач согласовывался с менеджером; спринт стартовал, и после этого в него нельзя было уже накидывать задачи просто так: менеджер мог добавить задачу в спринт, только предварительно из него что-нибудь выкинув. Для того чтобы определить, сколько можно включить задач в спринт, мы стали в пятницу же оценивать трудоёмкость задач (в часах). Программист не мог быть загружен задачами более 40 часов в неделю (в реальности это число было несколько ниже).
За счёт внедрения спринтов нам удалось отбиться от давления менеджера и привнести порядок в работу. Менеджер стал более внимательно относиться к приоритету назначаемых нам задач, жертвовать одной задачей ради другой.
Ежедневные стендапы пользы не принесли, и я их отменил. Проблема заключалась в том, что почти каждый программист команды занимался своим, независимым проектом, и ему было не очень интересно слушать про проблемы коллег. Такие пятиминутки хороши в команде, работающей над большой общей системой. Как я уже сказал, я не ставил перед собой задачу слепо внедрить ту или иную систему разработки, а пробовал те или иные элементы разных систем и неподошедшее отбрасывал.
Полезным оказалось внедрение отмечаний релизов. Мы заказали пиццу по случаю выпуска новой версии продукта. Это явно вдохновило программистов. К сожалению, идея не нашла поддержки у руководства компании и просуществовала недолго. Хотя, на самом деле, траты на это небольшие, а эффект определённо есть.
В целом, хочу сказать, что было интересно и здорово. Объём опыта, который я получил за это время работы, колоссальный, и он даже перекрыл предыдущие годы программирования. И теперь, приходя в новые компании в роли разработчика, я уже вижу, что можно быстро улучшить в производственном процессе, как повысить качество выпускаемого ПО и уменьшить стресс самих разработчиков. Что ж, надеюсь, мне ещё представится возможность попробовать себя на этом замечательном поприще тимлида.