ТЕХНОЛОГИИ
Просто сказать нет
Как не перегружать команду бессмысленной работой.
О, старая дилемма тактической работы и стратегической работы. Насколько сильно вы хотите повлиять на краткосрочную стоимость в пользу долгосрочной?
Ваша организация должна установить это на верхнем уровне. Ваша миссия теоретически может ответить на большинство вопросов — если она достаточно хороша.
«СДЕЛАТЬ ВСЕ ДЕНЬГИ YAAHHH»
не является хорошим заявлением о миссии.
На высоком уровне вы должны знать, что важно для вашей организации. Стратегия, в свою очередь, будет отражаться (как Гиннесс) в соответствии с вашими целями и должна объяснять мышление, стоящее за некоторыми решениями.
В компании, ориентированной на продажи, с вышеуказанной миссией цели могут сводиться к увеличению коэффициента конверсии на вашем основном веб-сайте. Другие планы могут сократить устаревшие инструменты и активы, чтобы люди могли сосредоточиться на большем количестве вещей, которые непосредственно влияют на миссию.
Устаревшие инструменты — это то, на чем я собираюсь сосредоточиться.
В целом, командам разработчиков программного обеспечения нравится работать с новыми приложениями. Они используют новые технологии, а создавать что-то с нуля — это увлекательно. Вы можете изменить мир с помощью новых технологий. Вы не можете изменить мир, написав инструмент, который позволяет пользователям массово импортировать записи в устаревшее приложение.
Программное обеспечение с истекшим сроком службы является более сложным и гораздо менее распространенным. Вещи тесно связаны везде. Часто монолитные приложения занимают центральное место во всей экосистеме периферийных систем.
Их нужно постепенно распаковывать и заменять по одной системе за раз, чтобы не полностью разрушить основы всей компании.
Вы можете работать с этими системами, пытаясь убедиться, что они по-прежнему стабильны, ошибки исправлены, сделаны обновления и исправления и т. д. Но есть люди, которые используют эти системы изо дня в день. Хорошие пользователи захотят внести изменения. Хорошие группы пользователей будут следить за обновлением процессов и пытаться оптимизировать свою работу. Несмотря на то, что системы не должны развиваться, отделы, которые их используют, захотят этого. (ну они должны захотеть, конечно не всегда так)
Подводя итог очень длинному вступлению, у вас есть старая система, которую нужно удалить, но люди все еще хотят ее обновить. Как сказать нет?
Некоторые из этих методов, конечно, могут быть использованы не только для приложений, срок службы которых истекает. Они могут быть переданы напрямую. Просто ваша причина сказать «нет» будет другой.
Искусственные ограничения
Первый способ сказать «нет» — это добавить искусственные ограничения. Одним из них является сокращение размера команды или увеличение количества приложений, которые они должны поддерживать. Группа людей может выполнять ограниченный объем работы, поэтому она, естественно, будет ограничена, поскольку команда не сможет взять на себя слишком много дополнительной работы. С увеличением количества систем когнитивная нагрузка будет высокой. Команда будет более чем счастлива уменьшить это; чтобы сделать их жизнь более управляемой.
Этот подход как бы резюмируется законом Конвея, которого я коснулся здесь:
Некоторое предостережение, однако, если вы работаете в компании, которая не обращает внимания на возможности команды и требует к завтрашнему дню странных нестратегических улучшений. Тогда ваша команда сгорит и — совершенно справедливо — уйдет.
Дросселировать работу
Одна из задач владельца продукта — регулировать работу команды. Таким образом, на них могло падать в основном отрицание.
Общение жизненно важно; не каждый пользователь будет знать общую стратегию. Возможно, они только что присоединились к компании или однажды почувствовали себя особенно продуктивно. Изменения — это хорошо.
В этом случае мягкого напоминания о том, почему вы говорите «нет», и изложения стратегии должно быть достаточно, чтобы отговорить случайного соискателя работы.
Стратегический барабан — это барабан, который вы обнаружите, что будете постоянно стучать. «Эта система должна быть выведена из эксплуатации…»
Невозможные запросы
Иногда невозможно выполнить запрошенное в требуемое время. Вам будут звонить, чтобы перенастроить вашу дорожную карту, бросить то, что вы делаете, и что-то сделать.
Если заинтересованная сторона хочет сделать x за месяц, но для команды это год работы. У них нет другого выбора, кроме как искать другие варианты и решения. Здесь может помочь прозрачность в отношении необходимой работы и причин, по которым она занимает так много времени. Не бойтесь обращаться к техническим вопросам, если это необходимо. Команды часто работают со сложными системами, и люди не всегда понимают, почему все не может быть простым нажатием кнопки.
Это способ
Самый успешный способ сказать «нет» — попытаться понять, чего пытается достичь пользователь. Довольно часто вам будет предложено решение, но когда вы действительно поймете проблему на их месте, вы сможете помочь и найти альтернативное решение.
Часто эти решения могут быть реализованы быстрее и даже не требуют усилий по разработке. Или ваша команда может оказаться не той командой, которая сможет предоставить решение. Можно привлекать других людей по мере необходимости.
Здесь есть предостережение: не стоит сутулиться и перекладывать работу на других, придумывая технически неизящные странные решения, которые можно подсунуть другим людям.
Цель здесь состоит в том, чтобы быть как можно более полезным и найти правильное решение, которое имеет приятный побочный эффект в виде уменьшения тяжелого труда в вашей команде.
См. The Trick для некоторых примеров того, как вы можете это сделать.
Оксюморон здесь в том, что вы можете очень много работать, пытаясь избежать работы.
Другие проекты
Держите ухо востро и знайте, что происходит в вашей организации. Знайте, какие проекты происходят и когда. Посмотрите, как они влияют на ваше программное обеспечение.
Эти проекты могут решить проблему заинтересованного лица или значительно упростить его жизнь. Достаточно просто указать, что через какое-то время жизнь станет лучше.
Или может случиться так, что после того, как другие проекты будут завершены, их требования будут более подходящими для этих проектов и будут реализованы гораздо быстрее.
Уменьшение масштаба
Проверенный метод заключается в сокращении объема требуемой работы. Может быть, простой отчет решит проблему вместо разработки программного обеспечения. Удовлетворяет ли этот запрос функции потребность и добавляет ценность? Или, может быть, это приятно иметь. Было бы лучше, если бы вы могли определить разницу между тем, что критично, и тем, что находится в чьем-то списке пожеланий. Опять же, вы можете действительно сделать это, только полностью понимая решаемую проблему.
Я видел, как расстановка приоритетов MoSCoW использовалась для нескольких проектов. Как правило, большинство предметов перечислены как обязательные, а остальные пункты не подлежат обсуждению. Некоторые из этих проектов вообще не должны были начинаться ;)
Темная сторона
Не так почетно задавать слишком много вопросов. Отправьте запрос в несколько ИТ-отделов, и вы обнаружите, что требования разбросаны по пустякам.
Задавать слишком много вопросов — это не плохо. Это помогает правильно понять требования и, что более важно, помогает заказчику консолидировать свои мысли.
Если кто-то не может утруждать себя проработкой деталей того, что ему нужно, то очевидно, что запрос не слишком важен для него.
Когда у команды недостаточно информации, чтобы правильно посмотреть на работу, все должно быть не так.
Здесь вы можете видеть, что я отхожу от наделенной полномочиями Agile-команды и больше склоняюсь к сервисной команде. Блирргхх.
Нео, ты знаешь эту дорогу
Если вы работаете над проектом или командой достаточно долго, вы поймете, что работает, а что нет. Новые заинтересованные стороны могут выдвигать утомленные прошлые просьбы, которые не сработали.
Имея некоторый опыт того, что работало и не работало в прошлом, несомненно, можно сказать «нет». Возможно, вы сможете сразу перейти к сложной проблеме, из-за которой все остановилось. Возможно, вы сможете лучше сформулировать требование, чтобы уменьшить нагрузку на команду.
Или, что более вероятно, у вас будет хороший разговор с заинтересованным лицом о том, почему раньше ничего не получалось. Они получат больше информации о вашей сфере, что может сформировать их мысли для будущей работы.
Эскалация
Вы многого не сказали, поэтому люди решат обратиться к своим непосредственным руководителям в надежде, что это вызовет взрыв в организации и снова отступит, так что вы получите огорчение от своего босса.
Отрицая токсичность такой работы, эскалация не всегда плоха. Это может помочь напомнить более старшим заинтересованным сторонам об их стратегии в первую очередь.
Причинение людям некоторой боли — надеюсь, не слишком большой ;) — снова подтвердит необходимость изменений и правильность выбранной стратегии. Люди будут раздражены, но хитрость в том, чтобы они расстроились из-за ситуации, а не вы или ваша команда.
Обернуть
Как владелец продукта или команда, вы будете постоянно делать приоритетные звонки.
Некоторые требования, такие как юридические исправления или исправления безопасности, должны быть выполнены, даже если система находится на последнем издыхании.
Помните, что эта тактика выведена явно из-за необходимости вывода программного обеспечения из эксплуатации. Если вы будете делать это с каждой функцией, которая появляется в новом приложении, вы не продержитесь очень долго.
Но продуктивность повышается, если вы говорите «нет» работе и фокусируетесь только на том, что действительно важно.
Гораздо труднее сказать «нет», чем просто взяться за работу.
Наконец, я оставлю вас с обменом, который у меня когда-то был:
«Я ненавижу создавать для вас работу, но мы могли бы зажечь здесь небольшую искру».
"Это нормально; с удовольствием борюсь с огнем».
Спасибо, что прочитали эту статью! Пожалуйста, оставьте комментарий ниже, если у вас есть какие-либо вопросы или отзывы.
Если вам понравилась эта статья, то, пожалуйста, купите мне кофе:
Крис Шелдон — руководитель проектов в DataArt Ltd. DataArt – это глобальная компания по разработке программного обеспечения, которая использует уникальный человеческий подход к решению проблем.
За свою карьеру Крис Шелдон был разработчиком программного обеспечения, скрам-мастером, менеджером по развитию и т.д. Он решил, что люди сложнее, чем процесс, поэтому теперь его внимание сосредоточено на этом!
Крис окончил Университет Рединга в Великобритании по специальности «Электронная инженерия и кибернетика».
Немного энтузиаст Agile, ботаник продуктивности и Wantrepreneur Крису действительно нужно решить, чем он хочет заниматься в жизни, и сосредоточиться.
Вы можете связаться с ним в LinkedIn, Twitter, Facebook или на его веб-сайте, ITsChrisSheldon где это сообщение было первоначально опубликовано.
