В свете того, что Мегамозг вновь воссоединился с Хабром, теперь можно ожидать, что аудитория обоих порталов также объединилась. Логично будет предположить, что Хабр будет привлекать большее внимание менеджеров, которым не чужд мир современных технологий. Поэтому наша команда SmartProgress решила подготовить статью на перепутье разработки и управления проектами.
Надеемся, что этот пост поможет управленцам лучше понять программистов и не наступать на те грабли, по которым вовсю ходит большинство менеджеров и руководителей — каждый желает, чтобы код работал как по маслу, но при этом начальство забывает о том, что необходимо девелоперам для разработки отличного кода.
«Замеры продуктивности»
Нельзя управлять тем, что нельзя измерить — так звучит одна из излюбленных аксиом гильдии менеджеров. Только вот как ни крути, но продуктивность разработчиков адекватно оценить еще никому не удалось. Над этим вопросом бились самые светлые умы IBM, Microsoft, Intel и многих других титанов IT-мира, и пока что та метрика, которой можно было бы измерять продуктивность программистов, найдена не была. Если вам это кажется абсурдом, то предложите свои размышления — а вдруг вы окажетесь правы? Тогда вы станете настоящей звездой в IT-вселенной, а о вас и вашей гениальности будут писать книги.
Итак, проблема — нет метрик, которыми можно измерять продуктивность разработчиков. Какой же выход находят менеджеры? Они с усердием пытаются измерять хоть что-нибудь — ведут учет ежедневно написанного количества строк кода или свежеотлаженных багов, число сданных в срок проектов и прочих не менее важных вещей. Худший сценарий в данном случае — это попытки мотивировать разработчиков и внедрять наказания за «невыполнение пятилетки» или затягивание со сдачей проекта. Ведь программисты не лыком шиты. Хотите побольше кода? Это можно сделать. Баги — будем фиксить в две смены, особенно если за это дают премию. Только на продуктивность под призмой качества самого кода такой подход влияет крайне негативно.
Как помочь этой беде? На этот счет написаны десятки трактатов, и единого мнения так и не найдено. Одно ясно: организовывая рабочий процесс и координируя создание программного обеспечения, не нужно давить на программеров своими метриками. Но пусть менеджеры не впадают в панику — им все еще остается масса вещей для измерения и учета. Например, можно (и нужно) отслеживать, какие именно препятствия замедляют работу над проектом, сколько времени занимают те или иные задачи — впоследствии это поможет более точно оценить сроки сдачи подобных проектов.
Мышление в духе «Я исправлю это потом»
В плане проекта всегда не хватает дней, а в днях — часов, чтобы создать все, что было намечено. Поэтому (и по многим другим причинам) разработчики закрывают глаза на баги и в ход идут «костыльные» решения, которые работают здесь и сейчас — как раз для сдачи проекта. Так появляется и накапливается технический долг, который когда-нибудь придется погашать. Чем больше долг, тем больше он разрастается на последующих стадиях разработки и тормозит проект. Получается замкнутый круг — хотели побыстрее, а получилось как всегда, то бишь с точностью до наоборот.
У каждого проекта есть технический долг — иногда с ним можно справиться сравнительно быстро, но нередко он разрастается до исполинских размеров. Чем больше долг, тем больше времени надо на его погашение, а время, как известно — деньги. Поэтому случается так, что проще написать новый код, нежели воевать со старым.
Как бороться с мышлением в духе «я исправлю все это потом»? В первую очередь руководителям и заказчикам следует прислушиваться к тому, что им пытаются донести программеры. Очень часто реализация лучших решений занимает больше времени и отодвигает сроки выпуска продукта, чего ни руководители, ни заказчики не любят. Однако впоследствии это себя оправдывает. Конечно, случаи бывают разные, но одно ясно наверняка — ни один разработчик не хотел бы заведомо ставить себе палки в колеса, ведь потом с последствиями придется справляться самостоятельно.
Слишком мало документации
Документация отнимает время, а девелоперам платят за написание кода, оценивают их работу по количеству написанных строк и отлаженных багов (коли иначе оценить не умеют). Менеджеры хотят результата — разработчики и работают на результат. «А как же документация?», — спросите вы. «А мы и так все помним, и обязательно все напишем, когда будет на это время. Чесслово!» — невозмутимо ответят вам программисты.
Слишком много документации
И хоть все привыкли к проектам без документации, но на самом деле очень распространены и проекты, которые погрязли в бюрократической трясине — слишком много слов и мало кода. Это опасно тогда, когда компания оплачивает документацию «на вес». Тогда вместо комментариев по сути дела можно ожидать длительных и задушевных речей о каждой мелочи кода, на прочтение которых уйдет несколько месяцев. Что хотели, то и получили.
Любовь к антиквариату
Зачем переписывать древний код, когда он еще работает? Зачем использовать новые технологии, когда есть старые проверенные решения? С одной стороны, это верные замечания, но не стоит забывать том, что сохранение старого кода — это время и деньги. Нужно все перевести с одного языка программирования на другой, это непросто и скрывает в себе множество подводных камней. Несомненно, программисты могут проделать огромную работу, изменяя и выправляя древние системы и шлифуя старую логику вместо того, чтобы продуктивно создавать новую и двигаться вперед.
Цирк на рабочем месте
Это здорово, когда в владельцы компаний помнят о таких классных вещах, как бильярд или пинг-понг в офисе. Но очень часто при этом все забывают о том, что для продуктивной работы девелоперам важно сосредоточиться на своем коде, а для этого необходима тишина. Беседы, стук клавиш, рингтоны и прочие другие «прелести» опенспейса вырывают разработчиков из абстрактного мира алгоритмов. И тогда им нужно время, чтобы заново переключиться на работу. Это секунды, минуты — но в масштабе целого проекта подобные вещи могут негативно повлиять не только на скорость написания кода, но и на его качество, а самое главное — пошатнуть хрупкое душевное равновесие самих программистов.
Пресловутые собрания
Менеджеры любят поговорить, и эти разговоры в большинстве случаев непонятны программистам. Известная история — менеджеры готовы часами обсуждать «организационные детали», не давая разработчикам сосредоточиться на основных задачах. Или другой сценарий — сами программеры на собраниях могут часами плакаться о всем известных багах вместо того, чтобы заняться их отладкой. Посему нередко собрания, направленные на повышение продуктивности разработчиков, не только не дают желаемого результата, но и действуют с точностью до наоборот. К тому же такие посиделки посреди рабочего дня отвлекают создателей программного кода от абстрактного мира алгоритмов, и чтобы вновь настроиться на рабочий лад, им необходимо время.
Как с этим бороться? Так как в собраниях все же есть немало позитивных сторон, то нужно в данном случае следить только за тем, чтобы не переборщить с их количеством и продолжительностью. Чем меньше, тем лучше. Обсуждаем только самое важное и максимально лаконично.
Если же вы решили пойти по следам некоторых прогрессивных компаний и всецело отказаться от собраний, то вам будут нужны хорошие механизмы коммуникации. Здесь тоже важна мера — не переборщите с письмами и отчетами, потому что для разработчиков это еще хуже собраний. А в том, чтобы эффективно работать с планированием, ставить цели и совместно идти к ним, вашей компании может помочь наш сервис, который также подсобит в отслеживании прогресса и повышении мотивации.
Итак, мы надеемся, что вам понравился пост. Может быть, у вас есть что сказать о факторах, которые убивают производительность разработчиков? Также будем рады увидеть в комментариях лайфхаки по повышению этой самой производительности.
Комментарии (25)
Danov
30.05.2016 10:40+1Эффективность «эффективных манагеров» постоянно упираются в з-н Эшби:
Разнообразие управляющей системы должно быть не меньше разнообразия управляемого объекта. На практике это означает, что чем сложнее объект управления, тем сложнее должен быть и орган, который им управляет
Т.е. управленец хорошего разработчика должен быть более продвинутым разработчиком. И кто же будет убивать курицу несущую золотые яйца? Т.е. переводить разработчика в управленцы? Конечно, это возможно на фабриках разработки ПО, в крупных интеграторах. А как быть в небольших коллективах? В итоге, в управленцы попадают не самые лучшие разработчики. А еще чаще люди «гуманитарного склада ума», т.е. особи с дефицитом логического мышления. И это проблема.
4410
30.05.2016 13:28Вы неправильно интерпретируете закон. Он говорит не о том, что начальство должно быть более компетентно в профессии рядового работника, чем рядовой работник.
AllexIn
30.05.2016 13:38-2ИМХО вообще нечего делать программистам в руководстве.
Руководство должно быть умным и адеватным. Программистские знания им не нужны. Должны быть доверенные технические спецы, которые будут не давать разработчикам обманывать с технической стороны. И в свою очередь не позволяет руководству допускать грубые ошибки в техническом плане. И всё.
Само руководство программистами быть не должно.brewerof
01.06.2016 20:17В армии отлично бы смотрелось — «офицеры не должны быть военными, пусть будут одни доверенные солдаты, которые не дадут другим недоверенным солдатам обмануть балбесов-командиров». Просто блеск
AllexIn
01.06.2016 20:33Бредовая метафора.
Но ок. Давайте от нее отталкиваться.
Важно ли, чтобы генерал знал как чистить винтовку и из неё стрелять? Я вот думаю что не важно.
Часто генералу вообще не приходится мыслить категориями винтовок.
Каждый руководитель должен знать какие инструменты есть у его подчиненных и какие задачи можно этим инструментом решать.
НА уровне солдата надо хорошо владеть винтовкой и знать её.
На уровне сержанта — знание винтовки это хорошо. Но уже начинает играть знание людей отделения. Потому что важнее знания винтовки знаение, кто из отделения лучше стреляет, то лучше бегает и кто лучше ползает, кто подвержен панике и т.п.
А вот начиная с капитана важность знаний о винтовках начинают расплываться. И чем дальше — тем больше.
Капитан уже должен ориентироваться в частях своей роты. И о винтовках он долежн знать, что они есть и исправны. И всё.
Генерал-майор — ему вообще на эти винтовки чихать. Ему надо понимать, как части его дивизии действуют в тех или иных обстоятельствах и как надо действовать тактически и стратегически.
Ах да. ПОчему я ваш аргумент про армию считаю бредовым? Да потому что очень большая часть высших командиров оружие в руках никогда не держало(кроме как на учебных стрельбах) и солдатами не были, начиная сразу с офицеров после подготовки в военных ВУЗах. Вы выбрали дико неудачную метафору, потому что она как раз опровергает то, что вы сами сказать хотели.AllexIn
01.06.2016 20:37P.S>
Еще парочка выдающихся моментов из армейской метафоры.
Верховный главнокомандующий вполне может быть человеком не то чтобы солдатом не бывшим, а вообще гражданским лицом.
Да что там верховный главнокомандующий.
История России знает Генерала-Армии, который был гражданским.brewerof
01.06.2016 21:42-1На сцене появилась история и гражданские генералы? Это уже было, директора колхозов, рулящие дивизиями и не знавшие с какой стороны пуля из ствола вылетает. Правда потом супостат купался в Крыму, стоял на Волге и катался в Сокольниках на мотоциклах.
Ладно, я не любитель пустых споров, творческих успехов вам.
Shamov
30.05.2016 10:50Забыли про самое главное. Больше всего продуктивность разработчиков убивают попытки управления разработкой и планирования задач. Попытка планировать разработку всегда очень быстро вырождается в ситуацию, когда разработчики сознательно преувеличивают время, необходимое на ту или иную задачу, чтобы всё-таки выполнить задачу в срок, даже если возникнут непредвиденные сложности. А затем начинает работать известный закон: «Работа всегда занимает столько времени, сколько на неё выделено.» Из пяти дней, выделенных на работу, которую можно выполнить за один день, один день будет потрачен на работу, а четыре оставшихся дня — это padding.
SkyHunter
30.05.2016 12:03И как, по-вашему, выходить из этой ситуации? Не планировать разработку?
Shamov
30.05.2016 13:14+1Не планировать нельзя. Но можно планировать так, чтобы сами разработчики не знали этих планов. От разработчиков требуется лишь дать первичную оценку сроков. А какие сроки после этого попадут в реальный план, им знать не нужно. И менеджер должен сам накапливать статистику по тому, насколько реальное время выполнения задач отличается от заявленного разработчиками. Исходя из этой статистики, для каждого разработчика можно рассчитать коэффициент пересчёта его собственной оценки сроков в то время, которое действительно следует выделить на задачу. Ключевой момент в том, что сами разработчики не должны знать этого реального срока, от соответствия которому зависит выполнение плана. В противном случае они подсознательно будут стремиться максимально совпасть с планами. Либо будут спешить и лепить костыли даже там, где можно было сделать нормально. Либо будут растягивать до неприличия, зная, что время ещё есть.
dmitry_ch
31.05.2016 07:55Главное, чтобы не получалось ситуации, когда ответ разработчиков «запрошенное клиентом в принципе невозможно» превращается в «мы будем счастливы нарисовать семь взаимно перпендикулярных зеленых линий красного цвета за неделю». Менеджмент при этом исходит из того, что разработчики не хотят браться за сложные, нудные задачи, но по факту способны их сделать хоть как-то. Клиент просит, а что он просит — не все не-разработчики понимают. И вот здесь дилемма: либо руководитель проекта разбирается в технической стороне дела, но тогда он будет не в фаворе у своего руководства (возьмется «отвлекаться на мелочи» и часто говорить клиент «нет»), либо разбирается только в общении с клиентами (читаем — «ни в чем не разбирается», как с точки зрения завязанных на него технических специалистов), но постоянно выглядит молодцом у своего рук-ва. Методом естественного отбора получаем то, что получаем )
Shamov
31.05.2016 08:07На самом деле, хорошее руководство очень любит, когда разработчики вовремя предупреждают его о том, что необходимо сказать клиенту «нет». Совершенно не разбираясь в чисто технических вопросах, оно обычно кое-что знает об управлении рисками. В противном случае вообще непонятно, что такое руководство делает на своём месте. А с точки зрения рисков самый страшный кейс — это когда клиенту уже пообещали, сказав «да», а на деле сделать обещанное никак не получается.
Throwable
30.05.2016 12:27"Нельзя управлять тем, что нельзя измерить — так звучит одна из излюбленных аксиом гильдии менеджеров."
Всегда привожу по этому случаю закон Гудхарта как контраргумент:
"Закон (принцип) Гудхарта заключается в том, что когда социальный или экономический показатель (KPI) становится целью для проведения социальной или экономической политики, он перестаёт быть достойным доверия показателем."
scotioti
30.05.2016 12:57+1В общем статья о том, что надо вводить Agile или ещё какую-либо «модную» методологию отработанную на заводах или швейных фабриках и превратить образованного программиста в раба, который будет отчитываться о лишних 10 минутах проведённых в туалете…
LifeKILLED
30.05.2016 13:49+3А зря, ведь в туалете часто появляются гениальные идеи.
dmitry_ch
31.05.2016 07:58Тогда кроме отчета по «туалетным» минутам нужно еще кратенький отчетик на три страницы за идеи, приходящие в туалетной комнате.
Через полгода будем иметь статистику самых «идейной» кабинок. Там видится апгрейд остальных, для приведения процента идейности к нужному уровню, указание столовой готовить «правильную» для посещения «идейного» места пищу, и план по числу туалетных идей.
Ух, это ж какое направление! «Аж дух захватывает!» )))
bigspb
30.05.2016 12:59Производительность падает от слишком многих субъективных и объективных факторов ))
Но, по опыту, есть удобный для работодателя и исполнителя, при этом не самый трудный путь к повышению КПД коллектива. Я о менеджменте знаний (Knowledge management) и спец. ПО для его постановки на предприятии специализирующемся на разработке.
AllexIn
30.05.2016 13:41На самом деле есть один(и, к сожалению, единственный) замечательный способ увеличения производительности — мотивировать разработичка. Мотивированный разрабочтик будет показывать высокую производительность и качественный результат.
Как мотивировать? Да я представления не имею. Еще ни одного годного совета на эту тему не видел. Деньги точно не работают… Другие мотиваторы результата тоже не показывают…
voopr
31.05.2016 12:34Безотносительно к содержанию (хотя проблема, затронутая в статье, вполне годная для обсуждения)
Есть в статье три слова: Программист, разработчик, программер. Последнее на каком языке? Правильное слово на русском длиннее всего на одну букву.
Извините если кого обидел, но это уже достало. Зачем использовать разговорные словечки в серьезной статье. Это ведь могут увидеть дети, а потом из них вырастают эффективные менеджеры которые носят дОговоры в пОртфеле.
dmitry_ch
До этой фразы (выделение мое):
считал, что это собственноручно написанная статья, а унылый «перевод для привлечения хоть какого-то внимания к компании» (
frekenbok
Спасибо за замечание, поправила.
staticlab
Судя по всему, компиляция из этого: www.infoworld.com/article/2606696/application-development/application-development-129821-15-workplace-barriers-to-better-code.html
dmitry_ch
Ну вот в том и вопрос, что 1) иногда кажется, что администрации ресурса на контент будто бы наплевать, 2) правила не требуют компиляции как-то помечать, и 3) корп. блогах можно писать вообще любой текст (а потом ссылаться на него, мол, «на Хабре-то писали, что...»), неважно, относится ли это к правде вообще каким-то боком.
Декларированные механизмы «саморегуляции» Хабра в этих случаях не помогают: стоит написать провокационную чушь, и мы имеем не массу минусов (которые корп. блогам не страшны), а рост комментов. Вывод прост: нормальный контент не даст пиара, надо писать дерзко, с вызовом, и получишь свое внимание публики.
Хотя нет, что это я? Администрация недавно упоминала, что Хабр переводят авторы западных сайтов, так что все в порядке, значит, качество всего контента — на «мировом уровне» :)