Перевод второй части статьи «What’s Common Between Opera Houses And Software Projects, or 10 Reasons Software Developers Go Overtime». Первую часть читайте здесь.
Что общего между зданиями оперы и программами? Создание и тех, и других часто проходит с нарушением графиков. Почему так происходит и что с этим делать, если вы разработчик или клиент? Мы попробовали с этим разобраться. Представляем следующие 5 причин срыва дедлайнов.
6. Работа над проектом это не только программирование
Забыли о QA-отделе? А они о вас – нет. Тестирование и исправление багов требуют времени.
Учтено ли время, необходимое на написание модульных тестов? Интеграционных тестов? Регрессионных тестов? И не забудьте, что для начала надо наладить билд-сервер.
…Время на настройку git, slack и wiki. Время, чтобы админы могли подготовить серверы. Время на развертывание. Кстати, включили вы в подсчеты время на написание скрипта для развертывания?
…Мозговые штурмы, планирование, стендапы и обзоры.
…Презентации. Подготовка к презентациям.
А также отпуск, больничные, поездки на конференции, отгулы, отсутствие интернета у удаленных работников, отключения энергии и прочие маленькие домашние катастрофы, происходящие время от времени.
Что делать разработчику
Учитывайте, что программированием все не ограничивается. Работа не заканчивается набором «git push» в консоли. Есть множество всего, что должно произойти, прежде чем этот кусок кода оживет.
Научитесь не говорить «готово», пока еще не готово. Это сбивает с толку и порождает необоснованные надежды.
Также случаются и непредвиденные вещи. Оставляйте для них какой-то буфер.
Что делать клиенту
Вежливо напоминайте о необходимости тестирования и развертывания. Особенно, если общаетесь с разработчиками напрямую. Если разработчик говорит «Я закончу сегодня», это еще не значит, что вы увидите свой функционал сегодня. Или завтра.
Поэтому хорошей идеей будет спрашивать, когда функционал будет поставлен, когда пользователи смогут его увидеть. Ответ может сильно отличаться.
7. Оптимизм
Разработчики, делая предварительные прикидки, часто бывают излишне оптимистичны. Это же легко! Я быстро это сделаю. Завтра будет сделано. Нет, через час. Просто подержите мою чашку с кофе и посмотрите, как я сейчас все запушу. А, нет, надо сначала установить IDE и сконфигурировать git. Но потом – всего час!
Что делать разработчику
Вспомните предварительные расчеты, которые вы делали раньше. Чем все закончилось?
Для подобных упражнений ведите журнал. Прежде чем начать работать над задачей, запишите, сколько, по вашему мнению, займет эта работа. По окончании запишите, сколько она заняла на самом деле. Затем просмотрите историю. Видите шаблон?
У команды может быть общий журнал (записи в jira, wiki, trello, post-it). Просмотр истории может осуществляться, например, в ходе ретроспективного совещания.
Совет дня: если такого журнала у вас нет, умножайте ваши начальные прикидки на число Пи.
Что делать клиенту
Умножайте все расчеты касательно времени на число Пи.
Серьезно. Это может показаться похожим на карго-культ, но это число магическим образом подходит для многих случаев.
Думаете, Пи это слишком много? Ну, если сделают быстрее, то будет приятный сюрприз. Если нет – вы были к этому готовы. Будьте пессимистом! Не ведитесь на расчеты этих сверх-оптимистичных разработчиков!
Попросите назвать диапазон времени. Ориентируйтесь на большую цифру. Опять таки – будьте пессимистом.
8. Постоянное давление
Послушайте, уже второй день, а еще ничего не сделано. Почему вы так медленно работаете? Нет времени на обдумывание архитектуры, начинайте кодить! Нет времени на тесты, бегом, бегом, бегом!
Люди по-разному реагируют на давление. Некоторые собираются и становятся более продуктивными. Некоторые замыкаются и начинают сомневаться в себе.
Многие люди под влиянием стресса допускают ошибки. Их исправление в дальнейшем будет дорогим.
На разработчиков часто давят, когда нужно выбирать. Если на чашах весов качество в долгосрочной перспективе и скорость в краткосрочной, под давлением разработчик может решить, что лучше сделать грязно и быстро, чем медленнее, но при этом лучше.
С течением времени, когда подобным образом реализовано много фич, код становится грязным. Это затрудняет реализацию нового функционала и увеличивает шанс не заметить ошибки. Такое состояние кода называется «техническим долгом». Долги, как всем известно, нужно возвращать, и чем скорее, тем лучше. Чем дольше вы откладываете оплату (чистку кода), тем больше придется «заплатить» (тем сложнее будет добавлять новые фичи и исправлять баги в старых).
Что делать разработчику
Главный вопрос: в чем причина давления?
Возможно, ваш клиент хочет почувствовать себя влиятельной личностью. В этом случае попробуйте объяснить ему, что это не только не помогает, а и вредит проекту.
Если дедлайн близок или вы в последнее время сбавили темп, или случилось еще что-то, дающее клиенту моральное право давить на вас, нужно найти способ увеличить продуктивность без потери качества.
Будьте разумны, не паникуйте. Если можете, поручите общение с клиентом менеджеру, чтобы он с ним договаривался.
Что делать клиенту
Доверяйте разработчикам. Не давите на них без крайней необходимости. Под давлением люди допускают ошибки и принимают не лучшие решения. А вам нужно, чтобы ваши разработчики мыслили ясно, ведь от этого зависит ваш проект.
9. Нерешительность
Эти две библиотеки обе хороши, какую же выбрать? У первой хороший функционал, а у второй – функционал отличается, но тоже интересный. И ни одна не совершенна. Может, написать собственную?
Какой JavaScript-фреймворк выбрать? Использовать базу данных NoSQL или SQL? MySQL или PostgreSQL? RabbitMQ или Kafka? Ruby или Python?
Порой разработчики не могут решить, как именно реализовать функционал, и застревают в бесконечном цикле дискуссий, прототипирования и сравнений.
Что делать разработчику
Глубоко вдохните и подумайте о заказчике. Это действительно важная часть проекта? Случиться что-то страшное, если вы выберете не самую лучшую технологию? Возможно, выбор билд-сервера не так уж важен.
Ограничьте время, которое отводите на сравнение вариантов. Например, решите, что на изучение и вариантов должно уходить не больше двух дней, а затем нужно прийти к решению.
Не позволяйте себе прокрастинировать, поскольку не можете решиться. Это лишняя трата времени, причем совершенно непродуктивная.
Часто лучшим подходом будет выбрать технологию, которую кто-нибудь в команде уже знает. Это сэкономит вам кучу времени на изучение совершенно новой, к тому же в команде будет человек, способный научить других.
Написание собственного решения с нуля следует рассматривать как самый последний вариант.
Что делать клиенту
Не давайте вашим разработчикам тратить слишком много времени на некритичные части. Помогите им понять, какие части проекта некритичны.
Если они решили реализовать собственное решение, библиотеку или фреймворк, когда таковые уже существуют, у них должны быть очень веские причины поступить так.
10. Некомпетентность
Это самая печальная причина срыва сроков. Люди, неправильно реализующие новый функционал, ломающие старый включением нового кода, не проводящие юнит-тесты, не имеющие регрессионных тестов. Люди, вообще не тестирующие то, что делают.
Некоторые не думают об архитектуре заранее, еще до того, как начнут писать код. Многие считают код более важным, чем продукт, и создают бесполезных монстров. Есть те, кто пишет слишком недолговечный код, неподдающийся расширению, нечитаемый, содержащий слишком много багов.
Порой разработчики страдают отсутствием мотивации и начинают тянуть кота за хвост. Ходят по офису, попивая кофе, общаются у кулера с водой, долго обедают, готовят речи для конференций, играют в видеоигры и обсуждают преимущества пробелов и табов. Делают все что угодно кроме работы. Одним словом, прокрастинируют.
Иногда команда прокрастинирует вплоть до близости дедлайна, а тогда начинает лихорадочно работать. Конечно, теперь им не хватает времени.
И, наконец, разработчики могут обмануть заказчика. Они могут взять деньги и не сделать ничего или сделать спустя рукава, не стараясь добиться качественного результата. Они могут раздувать расходы и просить увеличить сроки не имея для этого никаких причин, кроме жадности. Команда может отдать проект субподрядчикам, чей труд более дешев, не заботясь о клиенте, проекте и собственной репутации.
Все это симптомы непрофессионального поведения. И, конечно, встречается не только в сфере разработки ПО.
Что делать разработчику
Извините, но вы должны действительно многому научиться, прежде чем браться за важные проекты.
Подумайте о каких-нибудь тренингах и курсах. Потренируйтесь на проектах попроще. Найдите наставника, почитайте статьи, купите какие-нибудь книги. Относитесь к своей работе более ответственно. Помните, что от этого зависит ваша репутация.
Если вы замечаете, что работа вашего товарища не лучшего качества, или что он тянет время, – скажите ему об этом, поговорите с менеджером, примите меры.
Если вы менеджер такой команды разработчиков, вы должны отслеживать подобные проблемы в зародыше и вовремя реагировать. Возможно, следует быть построже или внести изменения в рабочий процесс, или дать разработчикам понять, что их усилия ценят, а хорошая работа вознаграждается.
Если все очень плохо и ваши усилия не улучшают ситуацию, спросите себя, как так случилось, что вы наняли некомпетентных людей. Как они просочились через ваш процесс найма?
А также подумайте, что вы можете сделать, чтобы помочь им стать лучше. Или с ними покончено и единственный выход – нанять кого-то другого?
Что делать клиенту
Извините, но вам, судя по всему, придется сменить команду.
Или очень плотно заняться той, что уже есть. В целом, вам придется стать их менеджером. Это отнимает много времени и раздражает. У вас, вероятно, нет для этого необходимых навыков. И разработчики, скорее всего, вовсе не будут этому рады. Как и вы. Но если ваш проект застрял на середине, у вас не всегда есть возможность расторгнуть контракт.
Я сама побывала в такой ситуации и не могу сказать, что мне этот опыт понравился.
Заключение
Я перечислила 10 причин (первые 5 по ссылке), по которым разработка ПО может потребовать больше времени (и денег), чем было запланировано. Весьма вероятно, что эти причины могут сочетаться даже в одном проекте. Например, я замечаю, что «Изменение требований», «Изменения в команде» и «Оптимизм» чаще совпадают, чем идут по отдельности.
Я надеюсь, что заказчики, прочитав это, поймут, что разработка ПО это сложный процесс. Многие проекты очень сложны, их тяжело как понять, так и спроектировать. И еще сложнее сделать предварительные расчеты. Я надеюсь, что заказчики смогут помочь разработчикам в этом деле.
Я надеюсь, что разработчики, прочитав это, станут чуть лучше понимать, что от них ожидается. Заказчики это люди, на которых мы работаем, поэтому очень важно сохранять с ними хорошие отношения, а это подразумевает откровенное обсуждение проблем. Надеюсь, разработчики узнают из этой статьи, как разглядеть и исправить на ранних этапах хотя бы самые распространенные из проблем.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]