Про роль техлида

Для кого эта статья?

В основном статья для технических лидеров команд разработчиков ПО и тех, кто стремится ими стать. И, конечно, для остальных, кого заинтересовала тема. Для тех, кому интересно мнение относительно роли технического лидера, и для тех, кто готов делиться собственными соображениями на этот счет.

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

Совсем немного о себе

Более 15 лет в разработке ПО. Опыт работы как в продуктовых компаниях, так и в аутсорсинговых, как в иностранных компаниях, так и в российских. Различные роли, включая технического лидера и архитектора.

Кто такой техлид

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

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

Попробуем определить, что вы, как технический лидер, должны делать.

Вы принимаете технические решения. Направляете, инициируете обсуждения при необходимости, разрешаете технические конфликты, контролируете. Ищите разные способы получения информации — метрики, отзывы или что-то еще, что приносит видимую пользу. Однако, нередко менеджмент требует от вас другого вида ответственности — за результат, сделанный за предсказуемое время, причем качественный результат. Часто принято считать, что вся команда несет ответственность за результат. Мы можем так говорить, но если за вами последнее слово в решении технических вопросов, вы можете сильнее других влиять на проект, беря таким образом на себя бОльшую ответственность. Также важно упомянуть, что отказ участвовать в решении какой-то проблемы или делегирование решения другому не избавит вас от ответственности, т.к. тоже является решением. Часть вопросов может быть ответственностью архитекторов или других заинтересованных лиц — об этом нужно знать и привлекать их при необходимости. Также не бойтесь спрашивать советы у коллег — это может помочь принять более правильное решение.
Вы управляете ожиданиями. Будьте предсказуемыми для своего менеджмента и заказчика. Знаете, что через 2 недели закончится итерация (спринт, проект), а вы с вероятностью 80% не успеете сделать одну из запланированных задач — соберите необходимую информацию о причинах и способах решения проблемы и обсудите с заинтересованными лицами, пока еще может быть время что-то решить. Оставите это на сюрприз в конце итерации — можете получить какой-нибудь неприятный сюрприз в ответ.
Вы в теме. Не проводя ревью кода и не участвуя в разработке, очень легко потерять контакт с реальностью, когда ваши слова (документы, письма и пр) говорят об одном, а код — совершенно о другом.
Вы уважаете коллег. Кто-то может назвать это спорным, но мне бы хотелось оставить это здесь. Если не будете уважать вы, то не будут уважать и вас, сегодня или завтра. Вероятно, не всегда вы сможете увидеть взаимность, но вы хотя бы пытаетесь, что делает вас уж точно не хуже.
Вы постоянно учитесь. Сфера ИТ настолько быстро развивается, что технологии, популярные всего 3-5 лет назад, могут быть устаревшими (неэффективными, не поддерживаемыми) сегодня. Выделяет на это время ваш работодатель или нет, это нужно и вам, и ему — найдите решение (у вас же 24 часа в сутках, а еще и выходные бывают — шутка). Работая долго с одним набором технологий, вы, вероятно, улучшаете свои навыки в них, но расширение кругозора позволяет видеть больше альтернатив и принимать более эффективные решения. Изучайте не только вглубь, но и вширь.

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

Процессы

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

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

Борьба со сложностью

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

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

Модульность

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

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

Чем же может помочь разделение на модули?

Заменяемость. Относительно несложными махинациями можно заменить модуль на совместимый с ним (имеющий подходящий внешний интерфейс). Например, один продукт вы можете собрать с модулем экспорта в PDF, а другой — в CSV. При этом остальная часть продукта не изменится. Или даже подменять модуль на лету в зависимости от каких-то настроек.
Уменьшение зависимости между функциональными блоками, выделенными в отдельные модули. Изменения одного модуля не будут затрагивать остальные модули, при условии неизменности контракта. В реальности, конечно, это не совсем так из-за частой недостаточной определенности контракта. Например, мы можем описать, что некий метод возвращает строку, но явно не уточнить ее максимальную и минимальную длину, формат или что-то еще, что может оказаться важным для вызывающей стороны.
Работа над разными модулями может вестись разными командами. Это будет более эффективно из-за меньшего пересечения в исходных кодах. Меньше необходимость обсуждать мелкие детали реализации, только интерфейсы, если эти модули должны работать друг с другом. Вы сможете добиться даже потенциальной возможности использовать разные библиотеки или даже языки, отдельно тестироваться.

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

Один способ разбиения двигает нас в сторону слоистой архитектуры. Бывает разное количество слоев, с разными смыслами, но общая идея в том, что каждый слой работает только со слоем, находящимся непосредственно под ним. Например, есть слои доступа к данным, бизнес логики и представления. Слой представления будет использовать только слой бизнес логики, но не доступа к данным. Бизнес логика — только доступ к данным, но не представления. А слой доступа к данным никаких других слоев использовать не будет. Таким образом получаем 3 модуля, с некими внешними интерфейсами и зависимостями. Это вертикальное разделение.

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

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

Заключение

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

ссылка на оригинал статьи http://habrahabr.ru/post/270259/