Connect with us

Разработка

Григорий Петров: Микроменеджмент

Что такое микроменеджмент? Это подход к работе, при которой руководитель работает в ракурсе “как”, а не в ракурсе “что”.

Григорий Петров

Опубликовано

/

     
     

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

Что такое микроменеджмент? Это подход к работе, при которой руководитель работает в ракурсе “как”, а не в ракурсе “что”. Задачи ставятся не от конечного результата, а как последовательность шагов, которые нужно выполнить. И работа проверяется также: не по тому, что задача решена, а по тому, правильно ли выполнена указанная руководителем последовательность действий. Плюсом такого подхода является то, что сотрудники становятся продолжением рук руководителя. Это хорошо работает для небольших команд, когда много ручной работы. К примеру, многие прорабы при строительстве или ремонте занимаются микроменеджментом команд из нескольких человек, по факту “отращивая” себе этим несколько дополнительных пар рук и используя их со всеми своими знаниями и опытом.

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

Если о масштабировании пишут во всех учебниках по управлению, то вопрос о применимости освещен гораздо хуже. Это часто “упоминается вскользь” или “понятно их контекста”, но обычно внимания этому вопросу уделено гораздо меньше, нежели простому и понятному вопросу масштабирования.

Искусство или Ремесло?

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

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

Golden section (ratio, divine proportion) and golden spiral

Golden section (ratio, divine proportion) and golden spiral

Но пока в подавляющем большинстве проектов работа программиста намного ближе к искусству, чем к ремеслу. Даже если в компании есть стандарт кодирования (о нем я уже писал, и еще напишу), развита практика code review (и о нем тоже) и используется единый набор тулчейн, набор библиотек, фреймворков – все равно каждый программист будет писать код “по-своему”. Просто потому, что картина мира у всех разная.

В чужую голову свои мозги не вложить

Множество раз я наблюдал следующую картину: после code review к разработчику подходит Team Lead и говорит примерно так: “Вася, ты не прав. Не так надо писать код. Сейчас я покажу тебе как надо”. И грустный Василий слушает про то, что в одном месте кода нужно было применить не наследование, а композицию, классу нужно было дать другое имя, а часть кода Team Lead вообще не нравится и нужно “переписать поаккуратнее”. Такой способ, хорошо зарекомендовавший себя у прорабов, бухгалтеров и других менее творческих специальностей, у нас работает крайне неэффективно. Суммируя изложенные выше причины, я бы выделил следующие недостатки у микроменеджмента применительно к разработке программ:

  • У большинства разработчиков подход к написанию кода отличается. Team Lead будет стараться “привить” всем свой подход, но для программистов будет тяжело писать код не в своем стиле. Это все равно, что писателю предложить писать в стиле другого автора. Да, многие так могут, но для большинства это будет тяжело. Падает скорость и комфорт разработки, программисты больше времени проводят в раздумьях “а как бы это написал Team Lead”, чем на написание самого кода.
  • “Обучение через пример” хорошо работает в технически простых областях. Начинающему строителю достаточно десяток раз показать, как правильно клеить обои, после чего у него начнет получаться не сильно хуже, чем у мастера. У нас, увы, еще не сформировались хорошие практики, поэтому большинство попыток Team Lead объяснить коллегам “как правильно писать код” будут малоэффективны. Безусловно, если каждый день показывать разработчику как можно сделать лучше – рано или поздно его профессиональный уровень повысится. Но на это нужно тратить время Team Lead, а по эффективности такой способ сильно уступает классическому обучению: чтение хороших книг, блогов, статей. Плюс не стоит забывать, что Team Lead обычно более сильный разработчик, чем его команда, и предлагаемые им в рамках микроменеджмента решения могут быть малопонятны менее опытным коллегам. А программист, создающий код, который он сам плохо понимает – это очень печальное зрелище.
  • Читать код иногда труднее, чем писать. Team Lead, тратящий время на то, чтобы разбираться в коде коллег и осуществлять микроменеджмент, тратит на это очень много времени. Снова скатываясь на аналогию с ремонтом: у нас нельзя просто пощупать обои и быстро определить, насколько хорошо они поклеены. Проблема сложности кроется в самой структуре кода, и микроменеджмент требует от Team Lead много сил и времени. Слишком много.

Panneau

Что же делать?

Если микроменеджмент это плохо – то как Team Lead’у контролировать работу своей команды, обеспечивать качество кода и соблюдение сроков? Как я уже писал про Team Lead, очень важно следить за сложностью и согласованностью создаваемого разработчиками кода. Фокус в том, что для этого совершенно не обязательно детально изучать код, тратя на это больше времени, чем разработчик потратил на его написание. “Взгляд сверху” позволяет обнаружить на ранних этапах фундаментальные проблемы и направить команду в сторону их решения. При этом крайне важно ставить задачи не в терминах “сделай вот так”, а в терминах “я вижу вот такую проблему – подумай и реши ее так, как считаешь нужным”. В дальнейшем я еще не раз вернусь к вопросу code review и расскажу о разных подходах и практиках, позволяющих соблюсти баланс между потраченными усилиями и принесенной пользой.

Более общий управленческий принцип, известный уже много сотен лет, звучит как “формулируй задачу в терминах цели, а не в терминах решения”. Используя практики управления, например метод построения коридоров, Team Lead необходимо направлять работу команды в нужную сторону, ставя задачи и обеспечивая неотвратимость проверки их выполнения. Это всегда баланс между двумя крайностями. Стоит сорваться в микроменеджмент, и работа начнет замедляться до скорости работы самого Team Lead. Но стоит ослабить контроль – и разработчики начнут экспериментировать с новыми технологиями, допускать архитектурные промахи и попадать в ловушки долгосрочного планирования, ухудшая архитектуру продукта и с каждым месяцем увеличивая риски.

Поиск такой золотой середины – одна из многих обязанностей Team Lead. Что еще раз доказывает, насколько его работа отличается от работы простого разработчика. На ум сразу приходит расхожая штука, что “повышая разработчика до Team Lead мы теряем хорошего разработчика и получаем плохого Team Lead”. В каждой шутке есть доля штуки, и есть у меня подозрение, что в этой конкретно шутке очень мало смешного.

Григорий Петров
Комментарии Facebook
Продолжить чтение
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Обучение

Разработка iOS 11 приложений на Swift

Стэнфордский университет опубликовал новую версию курса по Swift в iTunes U.

Леонид Боголюбов

Опубликовано

/

В новом курсе учтены все изменения, сделанные в iOS 11 и новой версии Swift.

Темы:

  • Инструменты и API, которые понадобятся для разработки приложений для iPhone и iPad/
  • Пользовательский интерфейс.
  • MVC-парадигма.
  • Анимации.
  • Многопоточность.
  • Работа с сетью.

Курс бесплатен и доступен для прохождения на iPhone и iPad. Язык – английский.

 

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Новости

Интересные материалы: 16.11

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

Опубликовано

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Разработка

Почему не надо патентовать идею мобильного приложения

Студия AppCraft рассказала нам, стоит ли патентовать идею мобильного приложения, а если нет, то как лучше подойти к развитию своего продукта.

AppCraft

Опубликовано

/

Автор:

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

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

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

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

Это долго и дорого

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

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

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

После этого вы можете получить отказ на регистрацию от патентного бюро, потому что описание недостаточно детальное, не содержит инновационности, дублирует уже существующие патенты и т.д. Только 56% патентов регистрируется, соответственно, 44% – отклоняется.

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

Практически всегда желание защитить бизнес возникает на стадии первой идеи. Как только прошло достаточно времени на обдумывание плана, сразу возникает мысль о защите еще будущего предприятия. Желание понятно, однако идея и ее реализация – всегда разные вещи.

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

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

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

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

Забывается главное

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

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

Если патент – неэффективный способ защиты бизнеса в самом его начале, то это вовсе не означает, что не нужно принимать вообще никаких оборонительных мер. В силу простоты и дешевизны можно использовать такие способы:

  • Купите домен с именем продукта. Хорошее имя дает сильный эффект, а при решении любых споров покупка вашего домена в более ранний срок, чем оформление торговой марки конкурента, решает многие вопросы.
  • Создайте группы в социальных сетях с названием проекта. Как и в случае с доменом, хорошие названия имеют и хорошие поисковые позиции, и неплохо запоминаются, и становятся недоступны конкурентам.
  • Зарегистрируйте торговую марку. Это не быстро в некоторых юрисдикциях (например, в России), но во многих странах осуществляется в течение нескольких дней и с минимальными затратами.

Итого

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

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

AppCraft
Комментарии Facebook
Продолжить чтение

Календарь

ноябрь

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньSmart Taler 2017

25нояВесь деньLadies Code: время технологий

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Наш Facebook

Популярное

X

Спасибо!

Теперь редакторы в курсе.