О том, что убивает продуктивность разработчиков
В свете того, что Мегамозг вновь воссоединился с Хабром, теперь можно ожидать, что аудитория обоих порталов также объединилась. Логично будет предположить, что Хабр будет привлекать большее внимание менеджеров, которым не чужд мир современных технологий. Поэтому наша команда SmartProgress решила подготовить статью на перепутье разработки и управления проектами.
Надеемся, что этот пост поможет управленцам лучше понять программистов и не наступать на те грабли, по которым вовсю ходит большинство менеджеров и руководителей — каждый желает, чтобы код работал как по маслу, но при этом начальство забывает о том, что необходимо девелоперам для разработки отличного кода.
«Замеры продуктивности»
Нельзя управлять тем, что нельзя измерить — так звучит одна из излюбленных аксиом гильдии менеджеров. Только вот как ни крути, но продуктивность разработчиков адекватно оценить еще никому не удалось. Над этим вопросом бились самые светлые умы IBM, Microsoft, Intel и многих других титанов IT-мира, и пока что та метрика, которой можно было бы измерять продуктивность программистов, найдена не была. Если вам это кажется абсурдом, то предложите свои размышления —, а вдруг вы окажетесь правы? Тогда вы станете настоящей звездой в IT-вселенной, а о вас и вашей гениальности будут писать книги.
Итак, проблема — нет метрик, которыми можно измерять продуктивность разработчиков. Какой же выход находят менеджеры? Они с усердием пытаются измерять хоть что-нибудь — ведут учет ежедневно написанного количества линий кода или свежеотлаженных багов, число сданных в срок проектов и прочих не менее важных вещей. Худший сценарий в данном случае — это попытки мотивировать разработчиков и внедрять наказания за «невыполнение пятилетки» или затягивание со сдачей проекта. Ведь программисты не лыком шиты. Хотите побольше кода? Это можно сделать. Баги — будем фиксить в две смены, особенно если за это дают премию. Только на продуктивность под призмой качества самого кода такой подход влияет крайне негативно.
Как помочь этой беде? На этот счет написаны десятки трактатов, и единого мнения так и не найдено. Одно ясно: организовывая рабочий процесс и координируя создание программного обеспечения, не нужно давить на программеров своими метриками. Но пусть менеджеры не впадают в панику — им все еще остается масса вещей для измерения и учета. Например, можно (и нужно) отслеживать, какие именно препятствия замедляют работу над проектом, сколько времени занимают те или иные задачи — впоследствии это поможет более точно оценить сроки сдачи подобных проектов.
Мышление в духе «Я исправлю это потом»
В плане проекта всегда не хватает дней, а в днях — часов, чтобы создать все, что было намечено. Поэтому (и по многим другим причинам) разработчики закрывают глаза на баги и в ход идут «костыльные» решения, которые работают здесь и сейчас — как раз для сдачи проекта. Так появляется и накапливается технический долг, который когда-нибудь придется погашать. Чем больше долг, тем больше он разрастается на последующих стадиях разработки и тормозит проект. Получается замкнутый круг — хотели побыстрее, а получилось как всегда, то бишь с точностью до наоборот.
У каждого проекта есть технический долг — иногда с ним можно справиться сравнительно быстро, но нередко он разрастается до исполинских размеров. Чем больше долг, тем больше времени надо на его погашение, а время, как известно — деньги. Поэтому случается так, что проще написать новый код, нежели воевать со старым.
Как бороться с мышлением в духе «я исправлю все это потом»? В первую очередь руководителям и заказчикам следует прислушиваться к тому, что им пытаются донести программеры. Очень часто реализация лучших решений занимает больше времени и отодвигает сроки выпуска продукта, чего ни руководители, ни заказчики не любят. Однако впоследствии это себя оправдывает. Конечно, случаи бывают разные, но одно ясно наверняка — ни один разработчик не хотел бы заведомо ставить себе палки в колеса, ведь потом с последствиями придется справляться самостоятельно.
Слишком мало документации
Документация отнимает время, а девелоперам платят за написание кода, оценивают их работу по количеству написанных линий и отлаженных багов (коли иначе оценить не умеют). Менеджеры хотят результата — разработчики и работают на результат. «А как же документация?», — спросите вы. «А мы и так все помним, и обязательно все напишем, когда будет на это время. Чесслово!» — невозмутимо ответят вам программисты.
Слишком много документации
И хоть все привыкли к проектам без документации, но на самом деле очень распространены и проекты, которые погрязли в бюрократической трясине — слишком много слов и мало кода. Это опасно тогда, когда компания оплачивает документацию «на вес». Тогда вместо комментариев по сути дела можно ожидать длительных и задушевных речей о каждой мелочи кода, на прочтение которых уйдет несколько месяцев. Что хотели, то и получили.
Любовь к антиквариату
Зачем переписывать древний код, когда он еще работает? Зачем использовать новые технологии, когда есть старые проверенные решения? С одной стороны, это верные замечания, но не стоит забывать том, что сохранение старого кода — это время и деньги. Нужно все перевести с одного языка программирования на другой, это непросто и скрывает в себе множество подводных камней. Несомненно, программисты могут проделать огромную работу, изменяя и выправляя древние системы и шлифуя старую логику вместо того, чтобы продуктивно создавать новую и двигаться вперед.
Цирк на рабочем месте
Это здорово, когда в владельцы компаний помнят о таких классных вещах, как бильярд или пинг-понг в офисе. Но очень часто при этом все забывают о том, что для продуктивной работы девелоперам важно сосредоточиться на своем коде, а для этого необходима тишина. Беседы, стук клавиш, рингтоны и прочие другие «прелести» опенспейса вырывают разработчиков из абстрактного мира алгоритмов. И тогда им нужно время, чтобы заново переключиться на работу. Это секунды, минуты —, но в масштабе целого проекта подобные вещи могут негативно повлиять не только на скорость написания кода, но и на его качество, а самое главное — пошатнуть хрупкое душевное равновесие самих программистов.
Пресловутые собрания
Менеджеры любят поговорить, и эти разговоры в большинстве случаев непонятны программистам. Известная история — менеджеры готовы часами обсуждать «организационные детали», не давая разработчикам сосредоточиться на основных задачах. Или другой сценарий — сами программеры на собраниях могут часами плакаться о всем известных багах вместо того, чтобы заняться их отладкой. Посему нередко собрания, направленные на повышение продуктивности разработчиков, не только не дают желаемого результата, но и действуют с точностью до наоборот. К тому же такие посиделки посреди рабочего дня отвлекают создателей программного кода от абстрактного мира алгоритмов, и чтобы вновь настроиться на рабочий лад, им необходимо время.
Как с этим бороться? Так как в собраниях все же есть немало позитивных сторон, то нужно в данном случае следить только за тем, чтобы не переборщить с их количеством и продолжительностью. Чем меньше, тем лучше. Обсуждаем только самое важное и максимально лаконично.
Если же вы решили пойти по следам некоторых прогрессивных компаний и всецело отказаться от собраний, то вам будут нужны хорошие механизмы коммуникации. Здесь тоже важна мера — не переборщите с письмами и отчетами, потому что для разработчиков это еще хуже собраний. А в том, чтобы эффективно работать с планированием, ставить цели и совместно идти к ним, вашей компании может помочь наш сервис, который также подсобит в отслеживании прогресса и повышении мотивации.
Итак, мы надеемся, что вам понравился пост. Может быть, у вас есть что сказать о факторах, которые убивают производительность разработчиков? Также будем рады увидеть в комментариях лайфхаки по повышению этой самой производительности.
