Лучший способ избежать сползания области как разработчика без управления проектом
Я работаю разработчиком в небольшом внутреннем отделе ИТ в финансовой фирме и работал над рядом проектов малого и среднего размера, которые практически не имели управления проектами. По-видимому, это всегда приводит к ползучести области и, следовательно, к несоблюдению сроков и необходимости жертвовать хорошим дизайном / кодом, чтобы удовлетворить пользователей / менеджеров в краткосрочной перспективе.
Что я могу сделать как разработчик, чтобы гарантировать, что пользовательские требования будут записаны до того, как будет написан какой-либо код, и что все запросы на изменения будут должным образом обработаны, учитывая требования и ожидания пользователей / менеджеров.
Благодарю.
15 ответов
В этом типе ситуации сужение области действия почти неизбежно, заинтересованные стороны не имеют времени, чтобы помочь с предварительным анализом, и нет никакого официального контракта. Я бы порекомендовал выбрать гибкую методологию, которая позволяет вам постоянно корректировать цели и ожидания. Что-то вроде схватки. Короткие циклы помогут заинтересованным сторонам увидеть результаты на раннем этапе и скорректировать требования, поскольку они лучше понимают проблему, и они будут держать вас от безумия, поскольку цикл спринтов позволит вам адаптироваться к этим изменениям.
Практически невозможно иметь полнофункциональную спецификацию, прежде чем начинать писать код. Особенно в небольших компаниях. Гибкий подход работает лучше, но это не должно удерживать вас от завершения проектов.
Что ты можешь сделать:
- Сообщите как можно больше о принимаемых решениях. Даже вы думаете, что ваш босс должен был это сделать. Желательно по электронной почте, чтобы никто не мог претендовать на невежество
- Если требуются новые функции, убедитесь, что все знают, сколько времени это займет. Не стоит недооценивать. Сделайте обоснованное предположение и умножьте число на фактор риска, в зависимости от риска функции.
- Когда проект достигает финишной черты, составьте список задач, которые еще предстоит выполнить, вместе с оценкой времени. Опять же, убедитесь, что все участники могут видеть этот список в любое время.
По сути, вам нужно убедиться, что все знают, что вы делаете. Это не обязательно заставляет проекты завершаться вовремя как таковые, но это служит зеркалом для менеджеров, поэтому они видят последствия своих решений.
Но в целом, общайтесь, общайтесь, общайтесь и станьте своего рода лидером мини-проекта.
Если у вас нет менеджера, который мог бы отодвинуться при запросе дополнительных функций, вам придется сделать это самостоятельно. Я бы опубликовал график выпуска и добавил дополнительные функции на будущих этапах проекта, чтобы вы не опоздали на весь проект из-за этих дополнительных функций. Сообщите людям, сколько времени эти дополнительные функции добавят к проекту и когда они могут их увидеть.
Самое сложное - это научиться говорить людям НЕТ, но это то, что вам нужно выучить.
Существует два типа ползучести прицела. Один из них заключается в том, что вы не получили хороших требований. Это приводит к неожиданным задачам, чтобы доставить то, что ожидается. Если это проблема, то вы можете потратить больше времени на сбор требований и строго документировать, что ожидается в каждом периоде. Получив это, вы можете создать ряд задач низкого уровня и оценки времени. Если есть перерасход времени, то, по крайней мере, вы будете знать заранее.
Второй тип проистекает из небольших функций, добавляемых в середине цикла разработки. Здесь вы должны научиться говорить "нет". Вы не всегда можете сказать "нет", но вам нужно выбирать битвы. И помните, этот тип ползучести не происходит от одной большой вещи. Это происходит от многих мелких вещей. Это смерть от тысячи бумажных рубок.
Не бойтесь сказать "НЕТ". Вежливо и профессионально, конечно. Не совершайте ничего, что вы не можете сразу же, невозможно. Не совершайте немедленно то, в чем вы не уверены.
Кроме того, не бойтесь взять книгу по управлению проектами, прочитать ее и применить, даже если вы применяете ее только для себя.
К сожалению, вам, по сути, придется самостоятельно управлять проектом и немного узнать об управлении изменениями. Вам лучше всего взять доступную книгу по управлению проектами (не PMBOK) и прочитать любые разделы по управлению изменениями.
В проекте, над которым я работал, нам удалось изменить
- Составление спецификации требований, которая подписывается заинтересованными сторонами
- Оценка того, сколько работы потребуется, чтобы построить то, что было указано
- Каждый раз, когда запрашивается изменение, оцените, насколько оно изменит объем требуемой работы, объясняя влияние на стоимость и дату завершения, вызванную изменением.
- Скажи нет изменениям, которые не включают изменения в расписании
- Получите подтверждение принятых изменений (включая принятие изменений в расписании)
- Ведите журнал того, какие изменения были запрошены и что было утверждено.
К сожалению, управление изменениями в моем опыте никогда не бывает веселым, и есть много мест, где что-то может пойти не так. Чаще всего я слышал о нереалистичных ожиданиях в отношении точности оценки и необоснованных требований от заинтересованных сторон (просто отвергая последствия внесенных вами изменений или игнорируя процесс с такими требованиями, как "просто сделай это")
Как только вы и клиент ознакомитесь с требованиями, заприте их с подписанным документом с требованиями. Все, что после этого - запрос на изменение, который стоит больше денег.
Это не работает, если клиент никогда не хочет подписываться. Посмотрите, можете ли вы установить разумные сроки в вашем контракте, такие как "срок исполнения мягких требований" и "срок выполнения жестких требований".
Очевидно, что должно быть какое-то пространство для маневра, и никогда не бывает сложного и быстрого способа выяснить, что следует пропихивать после факта, а что нет, но добавление жестких сроков и угроза дополнительных затрат, как правило, гарантируют, что к определенному моменту подавляющее большинство запросов находятся в неизменяемости, тем самым сохраняя часть вашего здравомыслия.
Я был в такой же ситуации много лет. Однако мой опыт был немного другим. Первоначально в моей компании я был одиноким волком. Совещания по требованиям были проведены мной. Собрав требования, я бы собрал приложение, и вот, это было не то, что хотели пользователи. Время восстановления, с одиннадцатью миллиардами изменений. Какой ужасный процесс. Все рассердятся от этого, мой менеджер, я, пользователи.
К сожалению, я обнаружил, что люди, которые слишком часто хотят получить программное обеспечение, не хотят тратить время на то, чтобы помочь вам разработать решение, которое решит бизнес-задачи, для которых они ищут решение. Они будут постоянно расплывчаты и не захотят что-либо делать.
По мере нашего роста мы нанимали некоторых людей в качестве менеджеров проектов, хотя они никогда раньше не управляли проектами разработки программного обеспечения и практически не имели технического опыта. Это привело к получению "конкретных" характеристик, с которыми согласились все, кроме меня, разработчика.
Конечно, результаты были почти такими же плохими, как и в исходной ситуации, но, по крайней мере, у нас была заинтересованность руководства в применении спецификаций. К сожалению, эти конкретные спецификации были наполнены нелепыми, а зачастую и по-настоящему невозможными потребностями.
После борьбы за здравомыслие в приложении, оно будет построено. Девять раз из десяти пользователи все еще были расстроены, потому что они неизменно вместе с руководителями проектов разрабатывали глупые решения, которые не работали для них.
И снова началось восстановление ада.
Теперь мы прошли полный круг. Все менеджеры проектов ушли, и у нас были довольно тяжелые увольнения, поэтому я снова отвечаю за весь цикл. К счастью, мы извлекли уроки из наших ошибок, и руководство по-прежнему стремится делать то, что необходимо для обеспечения соблюдения соглашений. Мы также немного изменили способ предоставления пользователям приложения.
Мы часто даем им небольшие порции и требуем, чтобы они тестировали их, и подписываем, что раздел - это то, что им нужно и нужно. Если это не так, любые изменения, которые они хотят, будут добавлены в конец проекта, и каждый будет проинформирован о том, как он изменит график. Мелкие изменения и прихоти быстро исчезают, когда на нижней строке это явно сказывается.
Ключ документация и видимость. У нас есть простая в использовании система отслеживания проблем, которую создатели требований используют для добавления в свои запросы функций. Они никогда не отговариваются от этого, но затем проводятся собрания, на которых рассматриваются запросы после того, как мы угадаем оценки для их кодирования. Если время ограничено, то теперь запрашивающие должны бороться за время кодирования друг с другом, а не просто ожидая, что это будет сделано. Тогда мы, как программисты, защищены от ползучести, поскольку им приходится обсуждать, как это влияет друг на друга.
Вам придется самостоятельно заняться управлением проектами. Узнайте о гибком управлении проектами:
http://agilesoftwaredevelopment.com/blog/artem/scrum-under-10-minutes-video
Создайте бэклог и вместо того, чтобы говорить "да" / "нет" изменениям или функциям, сортируйте их по приоритету "Хорошие" вещи, чтобы сделать вещи идеальными, всегда можно отложить до более поздних версий, и дать понять, что это и есть план. Сосредоточьтесь на минимумах, чтобы сначала получить функциональный продукт.
Сфера Creep - это все о неутвержденных изменениях. Читая ваши вопросы, похоже, вы знаете ответ, вам нужны требования, запросы на изменение и одобрения.
Если бы у вас были БА и ПМ, а также все остальное промежуточное ПО для управления, вы могли бы идти на попятную с заявлениями о требованиях, формами запросов на изменения, досками проверки изменений и т. Д. Однако я предполагаю, что это не то, что вам нужно.
Вы можете сделать все это просто. Сначала определите, кто является спонсором проекта. Кто скинул это и кому это принадлежит. Это должен быть один человек, который утверждает бюджет и планирование для вашего проекта. Вам обоим нужно придумать процесс, похожий на следующий, с которым вы оба можете согласиться.
Далее в Excel создайте лист для вашего реестра требований. Перечислите все требования. Дайте каждому краткое описание и оставьте столбец для более подробного описания, когда это необходимо. Также включены столбцы для тех, кто запросил требование, когда и если решение разработано, и если решение доставлено. Сядьте со своим спонсором и согласитесь, что это базовый уровень.
Теперь создайте лист регистрации изменений. Для этого нужен столбец для краткого описания, один для более подробного описания, дата, столбец для воздействия и один для утвержденной даты и утвержденной. Столбец воздействия является наиболее важным. Каждый раз, когда кто-то запрашивает изменение, вам необходимо выяснить, как это изменение повлияет на ваш объем, бюджет или график. Дополнительная функция может добавить 5 дней и 5000 долларов. Если вам нужно доставить к Рождеству, вы должны удалить пункт требования 1,2,3.
После того, как у вас есть свои требования и метод информирования об изменениях и воздействии, самое сложное - это то, что вы не можете принять изменение без одобрения вашего спонсора. Это утверждение может быть по электронной почте или что-то еще. Но для этого нужно прямо сказать: "Я одобряю изменение № 12". Без явного шага одобрения вы можете не беспокоиться.
Речь идет о минимальном объеме документации / процесса, который вы можете избежать. Основная цель состоит в том, чтобы убедиться, что влияние каждого изменения полностью сообщается, принимается и отклоняется правильным лицом. Этот человек не вы и, как правило, не тот, кто делает запрос на изменение.
Получив одобрение каждого полученного вами требования от менеджера, вы можете самостоятельно управлять проектом, но кто-то еще должен утвердить изменения до их реализации. Тогда вы можете использовать подпись в качестве рычага, чтобы сказать нет.
Следите за текущими требованиями. Когда клиент приходит и просит новую функциональность, убедитесь, что он знает, что добавление новой функции вызовет одно из следующих событий:
- Дата доставки будет перенесена назад
- Требование об отбрасывании должно быть отменено, чтобы освободить место для нового
- Или их новое требование не может быть выполнено
Как сказал Боб Кинг в своем комментарии, сказать "нет" в профессиональном плане - это не плохо.
Прочитайте книгу о Scrum и примените практику в вашем офисе. Это эффективно превращает таблицы в управление, заставляя их расставлять приоритеты в том, чего они хотят достичь. Слишком часто мы, разработчики, представляем огромный список требований и короткие сроки. С помощью Scrum вы разбиваете эти требования на задачи, определяете, сколько часов вы можете работать в течение определенного времени, а затем в начале этого отведенного времени проводите собрание, чтобы определить, какой приоритет имеет этот "спринт". И это еще не все, но настоящий гений, помимо управления вашими менеджерами, состоит в том, что он отсеивает требования "Cutesy", потому что приоритетом будет являться реальное ядро приложения. Моя жизнь как разработчика была намного приятнее, так как я внедрил ее в своей организации.
Не позволяйте функциям изменяться или углубляться, которые не являются взаимоприемлемыми для всех. Если вам нужно выбрать, бросьте что-нибудь еще. Решения должны принимать сами.