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”. В каждой шутке есть доля штуки, и есть у меня подозрение, что в этой конкретно шутке очень мало смешного.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Новости

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

Сегодня у нас мобильные облака, карьера разработчика Xamarin и новые библиотеки.

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

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

/

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

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

Медиа

Podlodka #43: Профессия – архитектор

Продолжаем разбираться, что ждет разработчика после достижения сеньорности.

AppTractor

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

/

Автор:

Podlodka

Переход в менеджмент мы уже обсудили, и в этот раз на очереди другой популярный вариант – карьера архитектора. Сергей Орлов, архитектор из Avito, помогает нам вникнуть в суть этой роли, определить её область ответственности и требуемый багаж знаний.

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

Дизайн и прототипирование

Создание шрифта с нуля за 24 часа

Графический дизайнер Джеймс Барнард бросил себе вызов – он захотел за 24 часа создать шрифт и отправить его в Google Fonts. Как он это сделал и что узнал в процессе — в нашем переводе статьи Джеймса.

Анна Гуляева

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

/

Я большой фанат One Day Builds Адама Сэвиджа. В начале дня у него есть только материалы, а в конце он становится обладателем чего-то, что он хотел.

Поэтому я бросил себе вызов: создать с нуля абсолютно новый шрифт и отправить его в Google Fonts за 24 часа.

В старом блокноте у меня были эскизы нескольких букв. Я хотел создать узкий шрифт без засечек, который можно будет использовать на постерах или на других больших изображениях. Во время работы в Men’s Health я использовал шрифты вроде Tungsten или Heron, которые выглядят ужасно в тексте, но отлично смотрятся в заголовках или промоматериалах (которые и были моей основной работой). Это был стиль, который я и хотел создать.

Очень грубые наброски

13:00, среда

Я отправился в Adobe Illistrator с двумя-тремя буквами, которые были у меня в эскизах. Я создал сетку из пяти строк – для линии нижних выносных, базовой линии, линии строчных, линии прописных и линии верхних выносных букв. Затем я определил ширину прописных букв и толщину основного штриха.

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

  • Линия строчных = 2 × высота линии верхних выносных / высота линии нижних выносных
  • Ширина основного штриха = ¼ ширины прописной буквы
  • Ширина строчной буквы = ¾ ширины прописной буквы

Вот как это выглядит на иллюстрации

Сначала я создал буквы O и B. Я решил, что эти буквы будут иметь не форму овала, а форму скругленного угла. Многие буквы будут выглядеть, как высокий прямоугольник, но O, B и D будут иметь скругленные углы вместо овалов.

Внешний угол имеет радиус 12 мм, а внутренний — 6 мм. С этими правилами я начал создавать прописные буквы.

Мой шрифт был очень простым, но с одним «украшением». Любая апертура, то есть, срез концов полуовала, должна была быть отрезана под углом. Самыми сложными буквами стали G и K.

Затем я приступил к строчным буквам. Это было сложнее, но с установленными правилами работать было проще. Я использовал больше «украшений», особенно в верхних выносных и нижних выносных элементах. Самыми сложными стали буквы f, g, a и e, так как они были абсолютно новыми.

21:00, среда

Я перешёл к другим символам, таким как восклицательный и вопросительный знаки. Я стал работать быстрее и успел создать около 35 знаков.

Утро четверга

Утром я довольно быстро закончил цифры от 0 до 9 и начал создавать файл с шрифтом. Это было совершенно новым опытом. Мой знакомый каллиграф Иэн Барнард посоветовал для этого программу Glyphs. Я скачал программу, посмотрел несколько обучающих видео и понял, что неверно создал файл в Illustrator. Поэтому мне пришлось вставлять каждый символ вручную и подгонять его под правила программы.

10:00, четверг

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

11:00, четверг

С расставленными интервалами я приступил к кернингу. Это стало очень болезненным процессом. Сначала я зашёл на этот сайт и вставил в их текст для кернинга свой шрифт.

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

Затем я конвертировал текст в прописные буквы и сделал то же самое для них.

12:59, четверг

Я экспортировал шрифт и конвертировал его в файл .ttf, чтобы отправить в Google. Несколько символов отсутствовали (квадратные скобки и символ копирайта), и я был уверен, что шрифт не примут. У меня также не было времени добавить различные знаки для поддержки разных языков.

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

Название шрифта? Odibee Sans (произносится как oh-dee-bee), то есть, One Day Build — ODB.

Заключение

Я отправил Odibee Sans в Google в мае 2017, и он все ещё находится в очереди на добавление. Команда предложила мне пока уделить время дизайну шрифта, хотя они признали, что это противоречит духу проекта.

Я поработал над шрифтом ещё один день. Я добавил все нужные знаки, а также внёс изменения примерно в 30 символов.

Более того, сейчас в шрифте существует более 1500 кернинговых пар, что стало значительным улучшением шрифта. А также я создал сайт: odibeesans.com.

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

Разработка

Как сделать собственный VR-шлем за $100

Максим Кутте, 16-летний разработчик, создал свой open source шлем виртуальной реальности.

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

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

/

Меня зовут Максим Кутте. Мне 16 лет и я со своими друзьями, Йонасом Сессоном и Габриелем Комбе, сделал свой собственный шлем виртуальной реальности. Он стоил нам всего 100 долларов.

Благодаря моему учителю, я начал программировать в 13. Каждый понедельник и вторник вместо кафе я с друзьями ходил в его класс.

Я потратил один год на создание простой 8-битной операционной системы и участие в конкурсе роботов.

Затем я заинтересовался виртуальной реальностью. И мы с друзьями решили, что неплохо было бы создать собственный мир в VR, в котором мы могли бы проводить время после школы. Но Oculus  тогда стоил 700 долларов, и мы решили создать собственный шлем.

VR для всех

Напечатанная на 3D принтере запчасть

Причиной всего стало аниме под названием Sword Art Online. Его главный герой находится в ролевой виртуальной реальности – и так я влюбился в VR. Я хотел понять все ее аспекты.

Я купил самые дешевые компоненты, которые мог, и начал, изучая основы физики и математики виртуальной реальности (правильное ускорение, первообразные, кватернионы…) А потом мы заново изобрели VR. Я написал WRMHL, а затем с Габриелем FastVR. Объединив все это вместе, мы получили гарнитуру стоимостью $100.

Полностью открытая гарнитура для VR и комплект для разработки

Чтобы ускорить время разработки, мы сделали FastVR – SDK с открытым исходным кодом для разработчиков, который легко понять и кастомизировать. Он работает следующим образом:

  • Главный компьютер шлема вычисляет его позицию в пространстве
  • Позиция из шлема отправляется в WRMHL и часть вычислительной мощности процессора тратится на обработку этого сообщения
  • Затем FastVR извлекает данные и использует их для рендеринга VR-игры

Все, что вам надо – сделать на основе открытых исходников шлем.

Почему open source

Я хочу сделать VR мейнстримом. Поэтому я обратился к Уссаме Аммару, одному из соучредителей The Family. Я обсудил с ним создание компании и запуск на Kickstarter.

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

Мы отправились в Кремниевую долину, и Уссама познакомил меня с главным архитектором в Oculus, Атманом Бринштоком. И они дали мне ценный совет: сделай все это open source.

Следующий шаг

Есть еще много технических моментов, которые мы хотим улучшить.

Сейчас мы работаем над автономной VR-гарнитурой –  у нас уже есть как упрощенная версия с более дешевым 3D-трекингом.

Все это мы скоро выпустим.

Как начать

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

 

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

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

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

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

Вакансии

Популярное

X

Спасибо!

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