Почему программисты срывают сроки
Вместо введения
Так уж сложилось, что в какой бы компании я не работал, наш отдел или группа разработки ПО почти всегда срывала сроки. Иногда мы не укладывались на два дня, а иногда на несколько недель. Обычно, нам не хватало от пяти до десяти дней. В результате мы либо задерживали поставку, либо сдавали работу с известными ошибками, недоделками, не проверенными частями, и затем пытались наверстать упущенное на следующем этапе разработки.
Старт очередного этапа, который начинается с доделывания прошлых задач, является очень плохой практикой, как показал мой опыт. И чем больше я работаю в таком режиме, тем больше мне хочется что-то поменять. Но прежде чем лечить какую-то болезнь, надо провести диагностику и отделить причины от симптомов. Итак, вот моя попытка выявить и “разложить по полкам” причины срыва сроков разработки.
Менеджеры (роль Ангелов)
Менеджер проекта — ключевая составляющая успеха. Я бы даже сказал, что наличие толкового управляющего это 50% успеха. А отсутствие такого человека это 90% провала. Почему же менеджер так значим? Ответ прост. Менеджер имеет достаточно власти и влияния, чтобы управлять как программистами, так и процессами в организации.
На мой взгляд, самым важным в работе менеджера является то, что он выступает посредником между программистами и “остальным миром”. Он может вносить выносить на обсуждение необходимость изменений процессов, требовать нужные материалы от других отделов, представлять результаты труда программистов и защищать те их интересы, которые положительно повлияют на работу компании.
Обычно, посредственный менеджер может совершить следующие ошибки, приводящие к срыву сроков:
- не пытаться обеспечить наличие программистов в нужном количестве и качестве (да, придётся вести как приём, так и увольнение);
- игнорировать наличие неточностей, неполноты и противоречивости в требованиях к ПО (эти проблемы могут “подточить” время в отдельно взятых итерациях, а могут и ломать несколько этапов, если изменения требований повлияют на архитектуру системы);
- не влиять на становление и развитие процесса разработки ПО (в частности, игнорировать проблему часто изменяющихся требований);
- не обеспечить исполнение установленного процесса как среди своих подопечных, так и в других отделах;
- не заметить личных проблем между членами команды и/или не решать их;
- не контролировать ход работ;
- не обсуждать с программистами сроки задач, которые он сам не может оценить;
- давать обещания по исполнению заведомо невыполнимых задач в сроки;
- давать обещание по исполнению задач, сроки на которые не были оценены.
Недостаточный уровень детализации задач, форс-мажор и малый опыт в оценке сроков — более тонкие причины их срыва. Управляющий с хорошим уровнем самообучения со временем научиться не допускать таких ошибок.
Черты, присущие хорошему менеджеру: мужественность, воля, честность, открытость и общительность, конструктивная критика и самокритика, справедливость, покровительство.
Программисты (роль Земледельцев)
К группе программистов я отношу и “чистых” архитекторов систем. Если же архитектор ещё и управляет людьми и процессами, то к нему выдвигаются и менеджерские требования, описанные выше.
Поскольку первичной задачей разработчиков является собственно производство продукта, самым главным требованием к ним является профессиональная пригодность. Сюда же относятся характер плюс личные качества и навыки. По собственному опыту знаю, что если компания маленькая, то фраза “работа в команде” не пустой звук. Как добиться синергии от группы программистов, я не знаю. Но я знаю, что чтобы её разрушить, достаточно такой мелочи, как отсутствие навыков общения. Вопрос коммуникации становится критичен, если в фирме практикуют “выращивание кадров”. Тут программист неизбежно будет либо наставником, либо подмастерьем, а то и тем и другим.
Разработчик должен критически относиться к написанному собой и другими коду, уметь поддержать коллег советом и делом, уметь не предвзято относиться к чужому совету, даже если он не был прошен.
Уверен, что любой менеджер по достоинству отметит программиста, если тот сможет заранее предупредить первого о проблемах со сроками работ. Лично мне поначалу было очень трудно сообщать своему шефу, что такие-то и такие-то “фичи” не будут реализованы, а баги “пофикшены”. Но со временем я понял, что это надо делать как можно раньше, чтобы можно было расставить приоритеты по задачам. Это, пожалуй, самый хороший способ “прикрыть задницу” менеджера от проблем с его собственным руководством, ведь как известно “предупреждён — значит вооружён”.
А вот, что может сделать программист, чтобы не поспеть к дэдлайнам:
- не обратиться за помощью к наставнику или менеджеру, если чувствует, что возникают серьёзные проблемы;
- слишком долго неэффективно решать вопросы, связанные с общением с другими отделами и/или организациями (на самом деле это подвид предыдущего пункта. Разумеется, тут надо звать менеджера на помощь);
- не контролировать или избыточно контролировать подмастерьев;
- не достаточно детализировать задачи и оценивать их сроки в начале очередной итерации;
- необоснованно не следовать расставленным приоритетам задач (или не оговорив это с менеджером);
- неграмотно автоматизировать некоторую работу или не автоматизировать её совсем (в первую очередь оптимизировать следует скорость разработки и если писать скрипт займёт больше времени, чем исполнять действия скрипта руками, то это “плохая автоматизация”);
- просто лениво/медлительно работать.
Отмечу черты, присущие хорошему разработчику: бесконфликтность, исполнительность, самообучение, ответственность, общительность.
Коммуникация
Про роль коммуникации было сказано выше. Общение происходит в очень разных плоскостях, но как бы там ни было, следует стараться избегать неэффективного общения. Ты разработчик, которого стопорят сотрудники другого отдела не давая консультации, когда она нужна — постарайся быстро обсудить это с ними и объяснить важность. Не помогло? Сообщи менеджеру и переключись на другую задачу.
Другой пример. Ты менеджер. Программисты Петя и Коля всегда спорят о том, как делать одни и те же вещи (скажем, holy war на тему стиля кодирования)? Введи обязательный стиль и укажи, где они имеют свободу. Или в более общем виде (не про стиль): найди арбитра, который сможет достаточно объективно судить споры Пети и Коли. Или сделай Петю или Колю ответственным за разные вещи, которые не пересекаются. Или “вставь пистон”, чтобы они поняли, что критика должна быть конструктивной.
То есть ищи решения проблемы коммуникации, а не закрывай глаза на это. Каждое решение может и не быть выйгрышным, но отсутствие решения это стопроцентный проигрыш.
Ещё один аспект коммуникации между людьми и между организациями заключается в том, что многие игнорируют живое общение. Лучший способ замедлить работу — использовать телефоны, чатики, скайпики, почты(!) и прочие заменители, когда можно просто прийти к человеку. Единственным оправданием для использования e-mail сообщений может быть необходимость уведомить кого-то в организации (возможно, внешней) о том, что задача поставлена перед другим лицом, и прочая рабочая переписка. Но в большинстве случаев это можно решить через систему учёта задач. Если же надо просто узнать у коллеги, как сделать что-то, и он сидит через кабинет — не ленись, сходи (разомнёшься заодно). Телефоны, чаты, скайпы это те инструменты, которые надо применять, только если они необходимы. Потери во времени от чатиков сложно измерить и они незаметны, и тем не менее, они очень велики.
Отдельной статьи заслуживает тема помещения крупной команды разработчиков в одной большой комнате “чтоб лучше работали и теснее общались”. Уверен, это решение сильно зависит от участников. Лично я не могу работать в шуме, а в команде 10+ человек обязательно постоянно кто-то разговаривает. Так что будьте осмотрительны перед принятием подобных решений.
Процессы (Законы)
Под процессами я понимаю те установленные формально и неформально порядки, которым надо следовать, работая в команде. К сожалению, далеко не все фирмам удаётся построить достаточно чёткие процессы, которым бы в целом следовал персонал. Порядки, разумеется, не должны перерости в сад бюрократии, но полное отсутствие их может рано или поздно привести к хаосу (очень вероятно, что энтропия в работе компании будет расти, если её сотрудники не склонны к организованности).
Хуже официального отсутствия процессов может быть только их наличие и несоблюдение. Положим, что в нашей конторе есть понятие закрытой задачи, которое означает, что задача выполнена окончательно и повторное возвращение к ней не допускается. Тогда любой человек будет стремиться выполнить задачу максимально качественно, чтобы отправить её в состояние “закрытой задачи” и не вспоминать больше. А теперь представьте, что закрытую задачу (то есть задачу, которую все признали закрытой) решают вновь поднять. Такое нарушение процесса абсолютно точно будет болезненно воспринято. Бесспорно, в реальности нельзя гарантировать, что к какому-то делу не придётся возвращаться, но тогда ошибкой было не учесть (или проигнорировать это) в нашей схеме процессов.
При описании процессов сложно представить все возможные ситуации, детализировать их и расписать в бумаге. Но самые важные моменты должны быть закреплены в обязательном к общему ознакомлению документе. Эти правила должны соблюдаться, а о сделанных исключениях из правил желательно, чтобы никто не знал.
Нарушение процесса может вызывать:
- явное или скрытое недовольство хотя бы одной из затронутых им сторон;
- поломку планов и сделанных предположений по срокам задач;
- снижение доверия исполнителей и руководителей к планам и оценкам;
- ухудшение общего отношения сотрудников к понятию процессов.
Указанные явления прямо или косвенно влияют на время исполнения задач негативным образом.
Общие инструменты
Все мы знаем, что для организованной разработки ПО нам всем нужна масса инструментов. К ним относятся и система учёта задач и ошибок, и общее хранилище документации и системы контроля версий и ещё масса интересных вещей. Проблем в налаживании работы коллектива программистов с использованием указанных инструментов почти нет. А если они есть, то они хорошо изучены и обычно излечимы. Но в случаях, когда в проекте участвуют ещё и не программисты, придётся потратить какое-то время, чтобы привить им привычку использовать эти инструменты на базовом уровне.
Так или иначе, разработка ПО накладывает это ограничение на компании, в которых серьёзно подходят к решению задач, даже если разработка и не является в ней приоритетным направлением. В одной из организаций, где я работал, время для осознания и признания потребности использования таких систем всеми участниками пришло почти через год после запуска проекта, хотя программисты пользовались этими системами с самого начала.
Чем раньше вы сможете начать использовать необходимые инструменты, тем больше времени вы сэкономите.
Библиотеки классов и фрэймворки
Не отходя далеко от роли программистов затрону проблемы с чужим кодом. На дворе двадцать первый век и мы уже не очень приветствуем “написание велосипедов” (или колёс). Большинство программ пишутся с использованием классных сторонних библиотек, а то и целых фрэймворков. RoR, Drupal, .NET Fw, Qt (продолжите список сами) это всё то, что помогает нам сразу начать писать продукт, а не его фундамент. Но есть маленькое “но”: люди часто ошибаются. Хуже всего, если мы (или кто-либо ещё) ошиблись с выбором инструмента для разработки ПО. В таком случае мы вынуждены терять время на протяжении всего этапа проектирования и этапа написания продукта, если всё-таки не переписывать на подходящей платформе.
Ещё бывает, когда какая-то библиотека предоставляет лишь часть нужных возможностей. Советую попробовать сразу посчитать, сколько времени займёт руками делать то, что отсутствует. Иногда оказывается, что некоторые вещи в принципе нельзя сделать. Много времени можно потерять, если сторонней библиотеке напороться на серьёзный баг. Придётся либо обходить его, либо исправлять самим (если open source), либо сообщить автору о баге, надеяться, что разработчик поддерживает проект, и ждать… неопределённый срок. Аналогично, очень плохо, если чужой код не имеет документации. Тогда время решения некоторых задач невозможно предсказать. Я называю такие задачи “чёрными дырами” и экстренно предупреждаю о них своего менеджера. Существует также неприятнейшая комбинация “баг” + “недокументированное и неожиданное поведение”.
К сожалению, я не могу даже дать стратегию, как оценивать время, если была выбрана неподходящая/недокументированная/бажная основа для проекта, поэтому считаю вопрос выбора основы для ПО вторым по важности после подбора хороших кадров.
Ограничения
Всё сказанное выше в большей степени подходит крупным компаниям. В случае с маленькими фирмами, в которых один человек исполняет несколько ролей, ситуация обостряется. Требования к участникам проекта ужесточаются, если ожидаемый уровень качества продукта и темпов его разработки не снижаются. В такой обстановке я настоятельно рекомендую очень тщательно проводить набор сотрудников и как можно более точно оценивать профессиональные и личные качества кандидатов.