Соблюдение подлинных сроков в качестве инженеров-программистов
17 февраля 2023 г.Как инженер-программист, я признаю, что сроки — спорная тема. Они оказывают значительное эмоциональное воздействие на организацию и существенно влияют на динамику команды.
Тем не менее в бизнесе существуют настоящие дедлайны. Я считаю крайний срок подлинным, когда он помогает организации воспользоваться возможностью. Это тот случай, когда выбранный момент времени представляет собой преимущество для клиента и/или вашей организации.
В этом посте я хочу рассмотреть несколько аспектов настоящих сроков, почему они существуют, а также несколько личных идей о том, как их использовать разработчикам программного обеспечения.
Прежде чем начать работу над этой записью в блоге, я нашел старый черновик статьи, которую давно хотел написать. Это было решительно против концепции сроков и доказывало, что качество трудно обеспечить, работая в срок.
Я исходил из точки зрения отдельного участника, увлеченного искусством создания программного обеспечения и полностью игнорирующего бизнес-аспект создания продуктов, приносящих пользу.
Мое мышление определенно изменилось: по мере того, как я брал на себя больше функций, ориентированных на управление, и в последние годы своей карьеры в качестве старшего индивидуального участника я пришел к выводу, что сроки — это отличная возможность повысить эффективность команды и принести всей организации вместе для достижения общей цели.
В то же время я осознаю последствия стресса и психического здоровья, которые они могут иметь в случае злоупотребления.
Что такое сроки и почему они существуют?
В большинстве случаев сроки являются лишь частью работы. Когда программное обеспечение является источником дохода для организации, оно должно соответствовать правилам времени и бизнеса.
Согласно Кембриджскому словарю, крайний срок – это
<цитата>время или день, к которому нужно что-то сделать
Кембриджский словарь — https://dictionary.cambridge.org/dictionary/english/
Когда сроки являются подлинными, момент времени считается преимуществом для клиента и / или вашей организации.
Устанавливая крайний срок, организация хочет воспользоваться возможностью: будь то привлечение нового клиента, сохранение существующего или более стратегический интерес к компании, например, путем представления новых функций на отраслевое мероприятие.
Чаще всего в отраслях B2B вы, возможно, работали над внедрением определенных функций, чтобы привлечь следующего клиента.
Может быть, контракт подходит к концу, и потенциальный клиент подчеркивает, насколько он заинтересован в вашем продукте, хотя в нем отсутствует одна функция, которая подходила бы для его варианта использования.
В этом случае ваша организация может принять решение предоставить запрошенную функциональность, чтобы завоевать клиента. В этом случае обязательству может быть назначен крайний срок.
В этом случае обязательство строго связано с возможностью получения дохода, которую ваша организация хочет использовать. Независимо от того, почему, крайний срок часто является фиксированным моментом времени, к которому организация должна предоставить функциональность.
Итак, новый крайний срок. Что теперь?
Когда команда инженеров получает информацию о новом проекте с крайним сроком, скорее всего, над ним уже ведутся работы. Таким образом, крайний срок — это прерывание, с которым нужно справиться. Как и в случае любой возможности переключения контекста, перед ней всегда возникает естественное сопротивление.
В зависимости от зрелости команды некоторые могут даже игнорировать это, пока не закончат то, над чем работают.
К сожалению, соблюдение сроков не может ждать: уже слишком поздно, когда вы об этом узнаете.
Я не говорю о том, чтобы бросить всю вашу текущую работу и сразу начать программировать, даже ничего не зная. Но, как я расскажу подробнее в следующих абзацах, важно начать оценивать масштабы и риски проекта.
По моему опыту, решающим первым шагом является достижение общего понимания того, что это прерывание означает для организации. Вполне вероятно, что критические работы уже ведутся. К такой работе может быть даже привязан крайний срок.
Поэтому крайне важно, чтобы все понимали, как это повлияет на существующие обязательства.
Нарушение существующей незавершенной работы иногда является необходимостью. В других случаях ресурсов может быть достаточно, чтобы уложиться в новый крайний срок без существенного влияния на текущие обязательства.
Тем не менее, важно, чтобы все предусматривали влияние, которое дедлайн окажет на текущую незавершенную работу. Этот аспект легко недооценить, полностью проигнорировать или оставить нерассказанным, но его необходимо выявить.
В этом отношении команда инженеров несет огромную ответственность: быть прозрачным и заявлять о проблемах на раннем этапе — это лучший способ облегчить обдуманные действия, а не надеяться на то, что к конечному сроку все получится.
Область действия Случайно
Соблюдение сроков может происходить без участия технических специалистов. Обычно это происходит, когда отделы, отличные от инженерных, имеют более непосредственное отношение к клиентам и лучше понимают открывающиеся возможности.
Возможно, это довольно распространенный сценарий в разных отраслях. Команды, работающие над возможностями роста, отделены от тех, кто создает продукт.
Как только крайний срок установлен, с ним естественным образом возникает неявная область действия. Теперь организация взяла на себя обязательство предоставить что-то, и это что-то нечетко определено, разбросано по разным веткам электронной почты, телефонным звонкам, онлайн-документам и презентациям.
Я называю это случайной областью действия. Для меня это первый неотъемлемый риск, с которым инженеры должны справиться.
Случайная область действия приводит к несоответствию между тем, что ожидает клиент, и тем, что в конечном итоге собирается предоставить организация. В зависимости от сложности проблемы, которую вы решаете с помощью своего продукта, разрыв может быть шире или уже.
Например, новому клиенту может понадобиться ваш продукт для учета очень специфических случаев, которые применимы только к их контексту.
Крайний срок — ваш последний шанс
Этот тип разъединения едва ли проявляется, пока продукт не окажется в руках клиентов, если только ваша организация не сможет разработать решение вместе с клиентом. Если этого не произойдет, крайний срок будет первым, когда вы получите отзыв о том, что вы создали.
Случайная область действия также означает, что по мере приближения крайнего срока дальнейшее взаимодействие с заказчиком может привести к возникновению дополнительных непредвиденных требований, что поставит проект под угрозу несвоевременной реализации.
В этом случае случайный охват легко приводит к переутомлению и дополнительному стрессу для вовлеченных людей.
Моя рекомендация лицам, принимающим решения, в отношении крайнего срока: не недооценивать масштабы и стремиться к тому, чтобы они были как можно более краткими и определенными. Воспринимаемая область действия всегда будет меньше, чем фактическая область действия в конечном итоге.
Это, конечно, сложный баланс, который должен учитывать потребности клиента.
Инженеры, действуйте сейчас!
Поскольку мы изучали, что такое случайная область, я сосредоточил свой анализ на том, что обычно происходит вне контроля инженерной организации. А теперь давайте поговорим о том, что могут сделать инженеры, когда дело касается сроков.
Хотя решение о том, чтобы взяться за проект к определенной дате, могло быть вне контроля инженеров, успех инициативы в значительной степени зависит от факта создания того, что было обещано, и, следовательно, от инженерной организации.
Достижение одной цели
Иногда передача ответственности от людей, которые соблюдают крайний срок, людям, которые должны создавать программное обеспечение, может привести к разочарованию и антагонизму. Это может иметь место по множеству причин.
Вот некоторые из них: (случайное или преднамеренное) отсутствие прозрачности в отношении того, чего компания пытается достичь, история необоснованных ожиданий в отношении существующих обязательств и новых сроков или общие политические проблемы между отделами.
Я не буду вдаваться в подробности этих организационных вопросов в рамках этого поста, но я просто хочу подчеркнуть, насколько важно, чтобы все задействованные отделы работали вместе для успеха проекта.
Крайний срок не следует воспринимать как нечто, установленное против инженеров, которые будут нести ответственность за доставку. Скорее, его цель — максимально увеличить возможности для успеха компании.
По этой причине работа над выявлением таких ожиданий и консолидация общего понимания масштабов проекта является первым шагом на пути к успеху любой инициативы, ориентированной на крайние сроки.
И да, предстоит непростой разговор, скорее всего, о пересмотре надежд и мечтаний о том, каким будет конечный продукт к назначенной дате.
Поскольку временное обязательство уже было принято извне, из этого естественным образом следует, что необходимо чувство срочности, когда становится известно о крайнем сроке.
Чувство срочности должно управлять следующими шагами вашей команды, когда дело доходит до понимания масштабов и обретения уверенности в том, что, по вашему мнению, может быть выполнено к указанной дате. Такая уверенность потребуется при пересмотре объема работ, а иногда и самого срока.
Чем раньше вы начнете это мероприятие по снижению рисков, тем лучше все вовлеченные стороны смогут справиться с любой потенциальной неудачей проекта.
Расширьте возможности команды
Скорее всего, команда уже занята рабочим процессом, поэтому у нее может быть естественная склонность сопротивляться изменению контекста и в значительной степени игнорировать крайний срок, пока не станет слишком поздно.
Хотя ограждение команды от ненужных прерываний, безусловно, важно для обеспечения качественной работы, приходит время, когда нужны все руки на палубе.
Команда, ответственная за успешную реализацию проекта, должна участвовать и понимать, почему организация допускает это прерывание, чтобы нарушить текущую работу.
Как член команды, не стесняйтесь задавать вопросы. Поймите, почему ваша организация делает это, что компания пытается получить от этой инициативы и каково влияние на существующие инициативы. Возьмите на себя ответственность за свою часть и не стесняйтесь говорить с заинтересованными сторонами.
Если вы в чем-то не уверены или заблокированы, проявите инициативу: ищите кого-то, кто может вам помочь, а не ждите, пока завтрашний день не поднимет ваши вопросы.
Если вы руководитель, убедитесь, что у команды есть доступ ко всей необходимой информации. Это ключ к развитию чувства сопричастности, которое необходимо для успеха инициативы.
Чувство сопричастности дает людям возможность находить решения и быть независимыми при принятии решений, в которых успех инициативы является их путеводной звездой.
Как лидер, защитите свою команду
Руководители инженеров должны помочь командам принять прерывающий характер сроков и внедрить методы, которые сводят к минимуму сбои, которые они вызывают. В то же время важно работать над тем, чтобы свести к минимуму негативное влияние сроков.
Баланс
Если вы как руководитель активно вовлечены в повседневную деятельность по разработке программного обеспечения или выполняете важные задачи для своей команды, вам может быть сложнее подготовить почву для своей команды, когда придет время решить проблему. крайний срок.
У меня нет рецепта гарантированного успеха, но по моему опыту руководители команд должны обдумывать время, которое они тратят на критически важные действия по разработке программного обеспечения, особенно в средах с большим количеством прерываний, таких как стартапы.
Если вы как руководитель берете на себя большие объемы работы на критическом пути к успеху команды, это ставит под угрозу вашу эффективность в руководстве командой во всех тех действиях, которые требуют значительных усилий по управлению ожиданиями и переговорам.
Поскольку дедлайны мешают работе, возможно, вы захотите создать возможности, которые помогут выявить их раньше.
Кроме того, старайтесь использовать повторяющиеся встречи с вашей командой в качестве места для общения с ними: это поможет уменьшить количество прерываний, чтобы люди в команде могли наслаждаться как можно большей частью непрерывной работы.
Регулярные встречи с другими отделами, не относящимися к инженерному отделу, также могут стать отличной возможностью для раннего определения сроков. Вы можете узнать об инициативах, которые могут привести к установлению крайнего срока.
В то же время вы можете использовать его как возможность сообщить, на чем в данный момент сосредоточена команда и какие последствия может иметь прерывание этой работы.
Принимайте трудные решения рано
Защитите свою команду от переутомления и выгорания.
Хотя, с одной стороны, наличие фиксированного момента времени для работы помогает лучше определить масштаб инициативы, это также может вызвать значительный стресс у людей в команде: это тем более актуально, если еще предстоит выполнить значительный объем работы. в то время как дата приближается в ближайшее время.
Ранние и частые проверки и видимость незавершенной работы — вот некоторые из инструментов, которыми организация должна помочь оставаться честной и заранее выявлять риски нарушения сроков: когда это происходит, пришло время попытаться пересмотреть дату (если это возможно). ) или отказаться от обязательства.
Однако пересмотр даты обычно требует новых временных затрат. На этот раз вы хотите быть уверены, что сможете выполнить доставку к новому моменту времени.
Внимание! Чем больше область действия, которую вы зафиксировали, тем выше будет случайная область действия.
Если вы собираетесь пересмотреть дату, инженерная организация должна сделать паузу и оценить, сколько работы было сделано и сколько осталось, прежде чем она сможет рекомендовать новую дату.
Остановить кровотечение
Отказ от обязательств также возможен, но его часто упускают из виду. Часто это происходит из-за предвзятости к обязательствам, что выражается в так называемом затопленном ошибка в стоимости.
По мере того, как команда продвигается к работе, может стать очевидным, что случайный масштаб, который она взяла на себя, намного превышает выгоды, ожидаемые от соблюдения сроков.
Возможно, было намеренно решено реализовать функциональность только для демонстрации, но по мере приближения даты становится очевидным, что инвестиции в ее создание намного превышают ожидаемую прибыль.
Время (и деньги), потраченные до сих пор, могут заставить организацию продолжать работу, даже если прекращение работы поможет остановить кровотечение. Одним из самых известных примеров этого является так называемая Ошибка согласования.
Практические сроки
Еще один способ подготовиться к непредвиденному срыву сроков в вашей команде — овладеть искусством фиксации в фиксированный момент времени. В рамках повседневной работы убедитесь, что ваша команда стремится разделить работу на части сопоставимого размера.
Как только это будет сделано, старайтесь всегда фиксировать внутреннюю дату. Затем, в рамках ваших ретроспективных встреч, проанализируйте, как вы это сделали. Сравните объем выполненных вами задач и оцените, насколько далеко или близко они были выполнены к первоначальной дате выполнения.
Непрерывное повторение этого типа упражнений поможет вашей команде чувствовать себя уверенно, когда дело доходит до оценки масштаба инициативы, ограниченной сроками.
Возможность обучения
Соблюдение сроков, нравится вам это или нет, является частью вашей работы как инженера-программиста. Борьба с ними или игнорирование их вряд ли заставит их уйти. Скорее думайте о них как о возможности обучения.
Если вы сознательно работали в направлении дедлайна, вы потратите время на такие действия, как сбор требований, оценка, управление ожиданиями и, надеюсь, разработка.
Как только проект будет реализован (или если он вообще будет реализован), воспользуйтесь возможностью извлечь из него уроки: ретроспективы — отличный инструмент, чтобы оглянуться назад и понять любую возможность улучшения, которую вы можете взять домой в следующий раз.
Кроме того, рассмотрите ретроспективы между отделами, где у вас есть возможность поразмышлять как организация о том, что пошло хорошо, а что пошло не так. Ответьте на следующие вопросы:
* Мы доставили?
* Насколько результат был близок к первоначально запланированному?
* Сколько случайных областей действия мы зафиксировали на этот раз? Стало лучше, чем в прошлый раз?
* Все ли мы понимали, насколько это будет разрушительно для существующих результатов?
* Как команда инженеров, ясно ли мы понимали, что на самом деле будет поставлено?
Вопросы такого типа резюмируют то, что мы обсуждали до сих пор, и помогают вашей организации выровнять успех инициативы; а также о том, что нужно изменить, чтобы иметь больше шансов на успех в следующий раз.
Сроки и сроки Agile
Я слышал аргумент, что сроки не соответствуют методу работы Agile.
Считаю ли я, что сроки соответствуют контексту Agile? ДА.
Я не сомневаюсь, что методологии Agile — лучший способ справиться с дедлайнами. Крайний срок дает вам фиксированный момент времени для работы. Нет лучшего способа, чем ограничение, помочь превратить идею в конкретный результат. Ограничение по времени тем более.
Я думаю, это потому, что, зафиксировав количество времени, вы остаетесь с пониманием того, насколько масштаб соответствует ограничению, и можете сосредоточить на этом всю свою энергию.
Как гласит юмористический закон Паркинсона:
<цитата>Работа расширяется, чтобы заполнить время, доступное для ее завершения
https://en.wikipedia.org/wiki/Parkinson's_law
Хотя это может быть правдой из-за дисфункций, это смелое заявление. В высокоэффективных Agile-контекстах четкое определение «готово» защищает вас от никогда не выпускаемого программного обеспечения, даже если у вас нет крайнего срока.
Как мы видели в сценарии, описанном в начале этого поста, в некоторых обстоятельствах желание воспользоваться возможностью становится частью определения «сделано». Соблюдение определенного момента времени считается значительным преимуществом для компании.
Когда это происходит, соблюдение сроков становится частью определения готовности, и за этим следует фактический объем проекта.
Сроки – это реальность в бизнесе. В таких случаях Agile-подход может помочь вам эффективно справиться с работой.
В частности, видимость незавершенной работы может помочь сформировать общее понимание разрушительного эффекта, который новый дедлайн может оказать на команду.
Фиксированный момент времени поможет вашей команде определить приоритеты тех аспектов функциональности, которые оказывают наибольшее влияние на заданные предполагаемые усилия.
Непрерывные итерации перед крайним сроком помогают вам убедиться, что вы создаете правильную вещь, и избежать неожиданных сюрпризов во время *большого взрыва* крайнего срока.
Если вам понравился этот пост, поделитесь им в своих кругах. Если вы хотите подписаться на меня в других социальных сетях, проверьте меня на @alediaferia@fosstodon.org, Twitter, или Linkedin.
Оригинал