Техническая сторона

(Technicality)

Оригинал статьи находится тут.

www.randsinrepose.com

В книге Правил Менеджмента Рандса очень короткий список того, что «должен» делать начинающий менеджер. Краткость это списка обусловлена тем, что понятие «должен» является абсолютом, а когда дело касается людей, существует очень мало абсолютов. Хороший менеджмент для одного человека оборачивается катастрофой, когда его применяют к другому. Что приводит нас к первому пункту списка того, что «должен» менеджер:

Оставайтесь гибким.

Единственная постоянная в менеджменте: считать, что вы повидали уже все, — плохая идея. Оставаться гибким — это единственная занимаемая позиция, когда постоянные изменения — это единственное, что постоянно.

Парадоксально, но второй пункт в этом списке поразительно не гибок и все-таки это мой любимый пункт, потому что я думаю, что он помогает установить базу для управленческого роста. Он гласит:

Перестаньте кодировать.

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

Когда я вижу, что новый менеджер прибегнул к кодированию, я говорю этому менеджеру: «Я знаю, что ты умеешь кодировать. Вопрос, умеешь ли ты управлять? Ты больше не ответственен только за себя, ты отвечаешь за команду и я хочу, чтобы ты разобрался как привести команду к решению этой проблемы без твоего кодирования. Твоя работа — выяснить как расширить свой горизонт. Я хочу от тебя многого, а не чего-то одного».

Хороший совет, да? Масштабируемость, менеджмент, ответственность. Очень популярные термины. Жалко только, что я не прав.

Не прав?

Ага. Не прав. Не полностью, но в достаточной степени, чтобы сделать несколько звонков своим бывшим коллегам и извиниться. «Тот мой совет перестать кодировать? Неверен. Да. Начните программировать снова. Начните с Питона или Руби. Да. Я серьезно. Ваша карьера зависит от этого».

Когда я начинал свою карьеру разработчиком в Borland, я работал в команде, которая делала Paradox for Windows, и эта комманда эта была большой. Только в Application Developement у нас было 13 разработчиков. Если посчитать и другие команды, которые предоставляли такие существенные технологии как ядро движка баз данных, графический движок, различные сервисы, то мы будем говорить о 50 инженерах, непосредственно работающих над продуктом.

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

Что мы, как разработчики, делали на протяжении последних 20 лет? Ну, мы написали чертову кучу кода. Горы. Настолько много, что мы решили, что может быть хорошей идеей облегчить его переиспользование, сделав его open source. К счастью, появился Интернет, который сделал эту задачу тривиальной. Если вы разработчик — попробуйте прямо сейчас. Поищите на Google Code свое имя и найдите какой-то код, о котором вы забыли, и который каждый может увидеть. Жутко, да? Не думали, что ваш код живет вечно? Живет.

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

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

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

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

Перестать кодировать?

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

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

У вас есть проблемы. Я понимаю. Давайте о них послушаем.

«Рандс, я мечу на директорскую позицию и если я продолжу кодировать, никто не подумает, что я могу масштабироваться».

Мой первый вопрос к вам такой: с того места, где вы сидите в своем скоро-уже-директорском кресле, видите ли вы, что разработка софта меняется внутри вашей компании? Если ответ «да», следующим вопросом будет: как она меняется, и что вы собираетесь делать по этому поводу? Если ваш ответ «нет», тогда вам нужно подвинуть свое кресло, потому что я клянусь вам, разработка меняется прямо в эту секунду. Каким-таким образом вы собираетесь масштабироваться, если постепенно забываете, как делается софт?

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

«Но, Рандс, кто-то должен быть арбитром. Кто-то должен иметь видение. Если я буду кодировать, я потеряю чувство перспективы».

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

Мой совет для потери перспективы:

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

2) Будьте способны нарисовать детальную схему архитектуры, описывающую ваш продукт, на любой доске в любое время. Я говорю не о варианте с тремя квадратиками и двумя стрелочками. Вам необходимо знать детальную схему, которая сложна, выглядит не слишком красиво и трудно объяснима. Это ваша карта для понимания практически всего в вашем продукте. Она меняется со временем и вы должны быть способны понять, почему эти изменения происходят.

3) Будьте ответственны на какую-то отдельную функциональность. Я буквально съеживаюсь, когда пишу эти слова, потому что чревато проблемами, но мне не кажется, что вы действительно сможете выполнить пункты 1) и 2) без какой-то фичи, которая принадлежит именно вам. Быть ответственным за фичу не только заставляет вас активно участвовать в процессе разработки, это также переключает ваш контекст с «менеджера, ответственного за все» на «человека, обладающего чем-то конкретным». Именно эта скромная, непритязательная перспектива напомнит вам о важности маленьких решений.

Я все еще съеживаюсь. Кто-то уже орет на меня: «МЕНЕДЖЕР ОТВЕЧАЕТ ЗА КОНКРЕТНУЮ ФУНКЦИОНАЛЬНОСТЬ??!?!» (И я согласен). Если вы еще менеджер, возьмите небольшую фичу, ладно? У вас все же много работы. Если вы не можете представить себя ответсвенным на какую-то функциональность, моим запасным советом будет исправить несколько багов. Вы не получите радости обладания, но вы получите понимание структуры продукта, которое вы никогда не приобретете, прогуливаясь по коридору.

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

«Рандс, если я буду кодировать, я буду смущать свою команду. Они не будут знать, менеджер я или разработчик».

Хорошо.

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

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

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

Один абсолют

Одна коллега в Borland однажды напала на меня за то, что я назвал ее кодером.

«Рандс, кодер — это бездумная машина. Обезьяна. Кодер не делает ничего кроме написания тоскливых строк бесполезного кода. Я — разработчик программного обеспечения».

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

Итак, я пересмотрел свой совет. Вы можете перестать кодировать, но...

Оставайтесь гибким и не прекращайте разрабатывать.

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно.І підписуйтеся на Telegram-канал редакції DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
Підписатись на автора
LinkedIn



7 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Хорошая статья, еще очень понравился последний комент Артура Ракицкого...

У меня свой взгляд на этот счет.Есть 2 взаимоисключающих фактора, которые влияют на работу менеджера: 1. Нужно разбираться в проекте.2. Нужно организовывать и обеспечивать разработку продукта.Я не зря использовал термины проект и продукт — они подчеркивают две точки зрения на результат деятельности всех участников. Для заинтересованных лиц (в том числе и для разработчиков) важен продукт — результат проекта. Он дает прибыль, бонусы, решает поставленные цели. Для команды разработки (и в большей степени, именно для разработчиков) важен проект. В нем протекает жизнь команды. При прочих равных (зп/, бонусах) люди выбирают проекты поинтереснее, посовременнее, поперспективнее. И для каждого участника проекта мера заинтересованности в продукте и проекте — своя. У разработчиков (и, зачастую, тестировщиков) больше заинтересованность в хорошем проекте. У заказчиков и потребителей — в продукте. Менеджер же находится на стыке этих интересов, балансируя временем и объемом работ (scope). И именно из-за времени и объема возникает взаимоисключение.1. Если уделять слишком много внимания разработке, менеджер перестает выполнять бОльшую часть функций менеджера, и становится тим-лидом. В этом случае самый лучший вариант — выделить отдельного человека на роль тим-лида, обучить и помогать ему.2. Если уделять слишком много времени продукту, менеджер становится бизнес-технологом, а иногда и продавцом (sales). В этом случае самый лучший вариант — выделить отдельного человека на роли User Experience, Business Analysis, Sales Manager (в зависимости от объема работ по каждому направлению), и координировать его работу.Но, зачастую, для выделения отдельных людей задач маловато, да и бюджет не резиновый... В этом случае совет, данный в этой статье, выглядит привлекательным, но лично я бы более четко описал работы менеджера в разработке: 1. Участие в разработке архиректуры (Conceptual + Logical Design) в качестве ревизора или помощника архитектора на протяжении всего проекта.2. Регулярные Code Review на протяжении этапов разработки.3. Регулярное участие в тестировании UI (особенно в части Usability) на протяжении всего проекта.4. Сборка продукта и оформление поставки. Не обязательно самостоятельно, можно дизайн сборки отдать разработчику.Все остальное время (а на разных этапах проекта оно будет разным) разделить приблизительно поровну между работой с требованиями и организацией процесса.И больше НИЧЕГО. Разработка отдельной фичи — это конечно очень хорошо, но кто будет выступать рецензентом данной фичи? В большой команде (10+ человек) мы такого человека можем найти, но мы ведь не говорим о больших командах! Не стоит отвлекаться от реалий, и выдумывать «а что бы такого еще позаковыристее нафигачить». Любая фича, которая входит в релиз, должна быть качественной. Обеспечить качество фичи один человек не в состоянии (со всеми оговорками и ссылками на современные методы и инструменты разработки). А разрабатывать некачественную фичу вместо того, что бы качественно выполнять работы по управлению проектом — это неразумная трата ресурсов. Если уж так хочется оставаться «в форме» и не терять навыки разработки, никто не мешает участвовать в свободное время в другом проекте:). Конечно, всегда есть место эксперименту и всегда можно заложить время на «не основные работы», но брать менеджеру за правило то, что создает риски и может приводить к проблемам — глупо. Разработать фичу в качестве исключения (если вдруг есть на это время) — да. Закладывать в план разработку менеджером фичи — нет. Планировать разработку фичи менеджером можно лишь в том случае, когда заранее известно, что для менеджера в проекте работы мало, и он по совместительству выполняет роль разработчика. Но в этом случае менеждер автоматически обязан передать часть своих обязанностей из 1−3 (выше) кому-то другому, кто будет контролировать качество его работ, как разработчика. Для небольших коротких проектов это вполне реально:).

Мое мнение, хороший разработчик может стать только побывав в шкуре тестера. Хороший менеджер станет только побывав в шкуре девелопера. Автор статьи развил мое мнение. Нужно не забывать и тратить часть своего времени не только на изучение новых методик своей текущей специальности, но и периодически поддерживать и развивать знания в областях подчиненных профи. Терь я понимаю, почему когда то в теоретической табличке, которую я видел, времени на образование менеджеру отделялось больше, чем его подчиненным, до 75% всего рабочего времени. А оно ж таки тяжко.

Спасибо. По кодеру понравилось.

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

Підписатись на коментарі