Сколько гибкость в бизнес-требованиях слишком много? [закрытый]
12 ответов
Спасибо за большой вопрос! Поскольку ваши процессы Dev Process Iterations уже находятся в 3 недели, решение, вероятно, не будет включать в себя улучшение управления рисками (например, толкая требования, которые могут измениться в конец цикла развития) или руководство ожиданиями (создание вашей команды, что изменения неизбежны ). Вместо этого я бы предложил несколько вещей:
выдвигают более высокие формальные барьеры для любых изменений требований: формы, одобрения, анализ воздействия, процесс управления изменениями.
Создание актуальной дорожной карты вместе с бизнес-пользователями, чтобы дать направление разработки и фокусировки. Это также даст возможность различных пользователей разрешить свои приоритеты и достичь соглашения о том, как проводятся ограниченные ресурсы.
Найти смелости, чтобы сказать «Нет, не в этом выпуске, и, вероятно, не в следующем либо», и выдерживают вашу землю.
Последнее, смелость не отдавать и не договориться при интенсивном давлении на изменения, которые будут размещать проект и программный продукт на опасность в долгосрочной перспективе, является одной из самых жестких частей работы менеджера проекта разработки программного обеспечения. Более того, потому что часто у вас не будет никаких жестких данных, воздействие изменений может показаться неопределенным и часто незначительным. В отличие от продуктов в строительстве или механических инженерных торгах, программное обеспечение по своей сути, по своей сути, потенциалью, возможно, немного изменится, может показаться, что не имеет большого значения, и это может быть не большая сделка, но потом еще один, и еще один на вершине и вскоре вы проигрываете отслеживать оригинальный дизайн.
Разработчики часто имеют решающее значение для их управления, которые позволяют изменять требования в конце проекта. Тем не менее, давление заинтересованного заинтересованного лица является интенсивным и часто PM, даже если он только что подразумевает, как если бы это их работа или карьера, на карту, на одной стороне весов и просто расплывчатое кишечное чувство на другом.
Не говорите, что вообще не должно быть никаких изменений, есть швальная сторона, иногда изменение имеет решающее значение для успеха. И это все о том, чтобы знать, когда сдаться и когда твердо стоять на земле.
Одним из ключевых задач управления является разработка процесса разработки и проектирования процесса разработки программного обеспечения, сродни для разработки самого программного обеспечения: все о поиске хороших компромиссов между противоречивыми требованиями и, в то же время, пребывание в пределах ограничений:
Программисты предпочитают столько информации о задаче под рукой и как можно раньше. Требования необходимы для создания и подтверждения проектирования программного обеспечения. И поздние изменения не понравились по причине: они заставляют программисты повторно оценить большие куски дизайна и снова пройти процесс проверки. Это требует много дополнительного времени и забота со своей стороны.
Менеджеры по развитию предпочитают планировать на основе стабильных требований, которые хорошо известны спереди. Большинство методов планирования предполагают большую степень уверенности, по крайней мере, в короткие сроки и среднего срока.
Бизнес-пользователи, понравится, чтобы нулевое время выполнить время для реализации требуемых изменений, они хотели бы, и часто имеют подлинную необходимость гибкости для изменения требований как можно более поздние. Ведь это создает огромное преимущество перед конкурентами. Однако независимо от бизнеса хочет иметь возможность поддерживать или даже увеличить скорость изменения программного обеспечения без увеличения ресурса; Бизнес также предполагает, что любое доставка программного решения будет надежно.
Но все три группы часто не обязательны друг к другу в другие потребности:
программисты не имеют знания о срочном порядке бизнеса, окна возможностей, завершительными преимуществами или угрозой соблюдения изменений.
Разработка менеджеров по времени и снова серьезно недооценивает усилия, необходимые для повторного дизайна; Или просто не хватает смелости, чтобы остановить бизнес-пользователей снимать себя в ногу.
Бизнес-пользователи просто не знают о времени заложенного времени, необходимого для доставки программного обеспечения, процесс разработки совершенно непрозрачен от того, где они есть, просто кажется, что вещи начинают заниматься дольше и дольше, а конечный продукт является полным беспорядок.
Некоторые советы:
Всегда делайте все возможное, чтобы иметь четкое и актуальное обзор приоритетов и непогашенной работы, что вы не потеряете какие-либо согласование требований до даже до сих пор - у вас нет фактов, чтобы утверждать вашу позицию или переговоры График, повторное переключение функций и не будет иметь другого выбора, а просто поддаваться давлению и обещаю невозможно. Следовательно, есть:
Расписание актуальной даты.
Очистить описания (или спецификации) и оценки (даже если это порядок величины) для всех выдающихся задач.
Все выдающиеся задачи в письменном виде, хранятся в одном месте.
С самого начала проекта определите требования, которые могут измениться:
расписать их как можно более поздние
. Установить ожидания команды DEV; Объясните способ, которым бизнес думает и любые существующие ограничения
нацеливаются на предоставление более общей функциональности, серьезно за исключением из программного обеспечения все, что связано с изменением, и может быть легко обрабатываться другими способами.
Посмотрите на политические требования, то есть требования, которые не имеют никакого другого звукового объяснения.
Установите прозрачный процесс управления изменениями:
Формальный процесс внесет изменение требований более дорогими, поэтому многие прихожие просто не будут вступить в ваш список.
У мужества «нет», когда вы думаете, что требование будет поставить под угрозу проект.
Избегайте перехода сверху с формальным процессом, это просто инструмент; Не рискуйте полностью потерять связь с конечными пользователями и заинтересованными сторонами.
] Одна из вещей, которая помогла нам решить эту проблему, это то, что в начале итерации мы все сидим вместе и просматриваем, над чем мы собираемся работать. Разработчики, клиент, QA и т.д. Мы обсуждаем это и оцениваем каждую деталь, над которой мы работаем. Это, как правило, заставляет клиента задуматься и уменьшает количество изменений, которые приходят позже.[
] []В противном случае, держите итерации короткими и за исключением того, чтобы вносить изменения после каждой итерации. Это идея Agile / Lean развития. [
]Нужно немного узнать о "гибкости" и привыкнуть к тому, что требования меняются. Они должны измениться, и вы должны создать код, отвечающий изменившимся требованиям.
Вы не никогда не не должны быть "сделаны". Это старая идея, которая проистекает из ложной идеи о том, что можно знать требования заранее, точно. Лучшее, что когда-либо можно было сделать, это знать все требования на определенный момент времени. Конечно, к тому времени, когда эти требования будут реализованы, первоначальные требования изменятся, как изменится бизнес, или как изменится мир.
"Сделано" - это иллюзия.
Да, "они платят" - разумный аргумент.
Это также ваш лучший (и единственный) контраргумент. Увеличение доходов и/или снижение расходов должно быть близко к сердцу любого делового человека.
Если вы можете сделать денежное дело в свою пользу, у вас будет больше шансов. Вы должны уметь количественно оценить некоторые последствия их решений.
Вы должны надеяться, что какие бы гибкие практики вы не ввели, они окажут желаемое положительное влияние на денежное благополучие вашей компании.
Удачи.
Lean - это больше дисциплина и недопущение потерь - на самом деле это не процесс. Мне кажется, что проблема скорее связана с общением. Другими словами, вы недостаточно цените переданные вам решения, чтобы считать их действительными. Ваша реакция, вероятно, вызывает у вашего «клиента» немного враждебности и превращается в вызов эго.
Первое, что приходит в голову, это то, что ваши «клиенты» не тупые. Это может показаться вам сбивающим с толку, но имейте в виду, что, если вы не взорвете эту дверь, вам нужно найти новую работу в новой компании, где клиент сможет выразить свои мысли в соответствии с вашими уважением. Хотите верьте, хотите нет - я не пытаюсь быть здесь резким, я просто предполагаю, что общение не проходит, и для меня это звучит так, как будто вы говорите: «Я не получаю то, что мне нужно».
Здорово, что вы пытаетесь улучшить свой процесс, но никакой процесс этого не изменит:
«Иногда мне кажется, что я бью головой о кирпичную стену». и «ему нужно побудить нашего [внутреннего] клиента [компании] заранее обдумать свои требования и приложить больше усилий, чтобы убедиться, что они исправлены, прежде чем предоставлять их моей команде разработчиков, чтобы начать работу»
... мне, что 1) вы разочарованы и 2) вы не уважаете то, что они делают.
Я работал с ними раньше - ненавижу. И я двинулся дальше - это было моим единственным решением. Однако, если вам нравится работа и люди, с которыми вы работаете, процесс ничего не исправит, а личные навыки. Здесь вы переходите от «разработчика» к чему-то большему - профессионалу (которым вы уже являетесь - я просто имею в виду более крупный).
Узнайте больше о деловой стороне дела. Попробуйте методы DDD и ubiq. lang, чтобы вы знали больше о том, что может произойти и что может измениться. В этом экономическом климате у вас не может быть длинного прямого пути - вам нужно адаптироваться и меняться, как и ваш бизнес.
Удачи!
В рамках Agile, особенно метода Scrum, я думал, что контент для итерации или спринта был определен в начале, а затем команда доставит этот контент в отведенное время (ваш пример 3 недели - это хорошо), ТОГДА вы просматриваете и корректируете изменения в следующем спринте.
Никто не любит использовать слова «фиксированный» или «подписанный» для описания того, как работает спринт, потому что это звучит слишком старомодным водопадом, но согласие на содержание спринта (например, набор пользовательских историй из Product Backlog) - это, по сути, одно и то же для каждого спринта, но выполняется чаще, чем в не гибких проектах.
Если вы не можете достичь даже такого соглашения в течение нескольких недель, значит, ваш клиент действительно сжигает деньги без уважительной причины, кроме списания налогов.
Вы можете работать над этим вопросом на двух фронтах.
Один - внутренний. Переход к подходу, который ожидает много изменений в требованиях на протяжении всего времени, должен немного уменьшить ваше (и вашей команды) разочарование. Теперь вы пытаетесь заполнить работу на 3 недели вперед. Некоторые команды работают со Scrum, используя 1-недельные итерации, которые делают планирование более частым (еженедельным), но также уменьшают вероятность того, что что-то изменится во время итерации. Вы даже можете пойти дальше и попробовать Kanban, где вы меняете приоритеты на протяжении всего времени, и все же с инженерной точки зрения это скорее порядок, чем хаос.
Другая вещь - это работа с бизнесменами. Им действительно все равно, что они сжигают деньги, это может быть тяжело, но даже тогда вы можете попробовать установить некоторые техники , которые изолируют их постоянно меняющееся решение от команды (например, сделать управление изменениями довольно формальным или привлечь их к организации приоритетов всего отставания каждый раз, когда вы планируете работать в течение другого периода времени).
ЭДИТ - Так как вы говорите, что их не волнует продвижение вперед, то, возможно, вы должны признать, что вы вообще не участвуете в проекте разработки: вы занимаетесь исследованиями. Там нет жестких сроков, и у исследований разные цели. Обычно целью является не работающее программное обеспечение, а просто понимание или полученные знания.
Итак, если вы измеряете "полученные прозрения/знания" вместо "готовое к производству программное обеспечение, разработанное", вы, возможно, делаете большие успехи и получаете огромное удовольствие.
Если вы не получаете удовольствия от исследований, не волнуйтесь: просто предложите взять очень неопределенный материал из вашего проекта по разработке программного обеспечения и создать для него исследовательский проект по созданию прототипа с явными целями.
Одна вещь, которую я нашел, уменьшает количество изменений в требованиях, заключается в том, что каждый раз, когда они меняют или добавляют новое требование, вы изменяете крайний срок и стоимость. Когда вы вносите изменения без ошибок относительно того, как это меняет сроки и стоимость, то они захотят мир, когда они понимают, что есть цена, прилагаемая для всех этих изменений, то они обычно будут гораздо более разумными. Если интофические требования сомнительны, не предоставляйте оценку времени или часовой оценки, пока вы не думаете, что основные вопросы, которые у вас есть ответы.
В отношении:
- Они платят нам, поэтому мы должны просто делать то, что нам говорят
, это все хорошо, чтобы начать. Но более длительный срок, если клиент не убежден иметь какой-то процесс, они собираются увидеть качество и производительность страдать и почти наверняка обвиняют вас за это.
Работа программного обеспечения не стоит бессмысленно создавать, что запрашивает клиент - это то, что предоставляют дешевые азиатские команды Asian Outsource - но помочь клиенту выяснить, что им нужно, и в некоторых случаях рассказывать их они хотят.
Архитектор не ожидает, что его клиент говорит ему точно, где идет каждое окно, это его работа, чтобы принять свое видение и производить что-то полезное и реальное.
"Они платят, так что просто делай, что тебе говорят, и не спорь" - это разумно, но приводит к тому, что один хочет бездумной работы, как: "Чтобы избежать споров, тебе придется делать все , что я думаю". Ты не против?" Посмотрим, какой будет реакция. Это в каком-то смысле обостряет ситуацию, но иногда плохая игра "Что если" должна быть разыграна полностью.
Вероятно, есть какая-то средняя позиция, где можно сказать: "Это то, чего мы хотим сейчас", и это то, что мы делаем, а затем предлагаем улучшения. Изменение желаний - это часть процесса, так как единственный способ узнать то, чего вы не знаете - это, как правило, трудный путь.
Контр-аргумент состоит в том, что команда должна испытывать чувство гордости за свою работу, и если то, что будет доставлено, будет снова и снова рассматриваться как дерьмо, то в какой-то момент это сожжет большинство людей. Вы не возражаете против высокой текучести кадров? В одних местах нормально сжигать людей, а в других не так уж и много. Как бы Вы хотели бегать кругами или на большом хомячьем колесе в течение дня или двух? Разве это не звучит весело? ;)
У вас есть разумные основания для беспокойства, но главное - иметь некоторую гибкость, чтобы все изменилось так, чтобы в то время, как первая поставка может работать по требованию, это больше не действовало, и поэтому вместо этого нужно сделать что-то другое. Я вспоминаю то, что говорил нам бывший руководитель команды: "90% вашего кода, вероятно, будет выброшено". Просто так это работает, прими это". Как бы грустно это ни звучало с точки зрения большой работы с небольшим количеством хороших результатов, в большинстве случаев это кажется правдой.
Один маленький момент, чтобы добавить об этой гордости, заключается в том, что книга Дейла Карнеги "Как завоевать друзей и оказать влияние на людей", имеет в качестве одного из своих принципов в разделе "Быть лидером": Как изменить людей без обид или обид:"
Дайте им хорошую репутацию, чтобы жить.
В книге есть несколько историй, иллюстрирующих это.
Что это звучит так, как вам нужно, это принять эволюционные прототипирование. Однако, чтобы помочь противостоять некоторым из того, что вы чувствуете, когда они делают еще один запрос на изменение, вы должны сказать «Да, но он отложит проект к х дням / недели / месяцы и увеличить стоимость y». Если они рады платить, будьте счастливы работать. «Они платят» - это действительная причина.