Как вы управляете запросами функций и изменениями программного обеспечения? [закрыто]

Я инженер-программист, и за последние несколько лет я фактически стал менеджером программных проектов просто потому, что его нет. Таким образом, чтобы сохранить наше здравомыслие в отделе R & D / Engineering, клиенты привыкли обращаться ко мне со своими запросами. У меня нет опыта в этой области, поэтому я впервые выступаю в качестве менеджера проектов по разработке программного обеспечения. Я управлял другими вещами, но не программным обеспечением.

Итак, как вы управляете программными проектами и отмечаете приоритеты? Запросы поступают через нечастые промежутки времени, поэтому мы вполне можем работать над чем-то для кого-то другого, а затем приходит другой человек с «спешной» работой, над которой нужно работать. Проще сказать «первым пришел - первым подай» или это человек с наибольшим количеством денег?

Я обнаружил, что чем больше клиент жалуется на то, насколько срочен его запрос, если он не является самостоятельным разработчиком, это, как правило, хороший знак того, что запрос вообще не является срочным. Один из моих профессоров в колледже всегда говорил нам не позволять срочно прервать важное.

Я обычно классифицирую запросы в следующем порядке (YMMV):

1. Проблемы, связанные с недавним обновлением или миграцией (наиболее важные).
2. Исправления безопасности.
3. Нарушена функциональность существующей системы.
4. Нарушена функциональность RC и бета-функций.
5. Платные функции запросов.
6. Запросы на исследования и разработки от значительной части пользовательской базы.
7. Запросы на исследования и разработки только от одного или двух пользователей.

Этот последний на самом деле занимает гораздо больше времени, потому что они, как правило, отвечают тем «срочно, мне это нужно вчера». В действительности, пользователь редко полностью задумывается о том, что ему действительно нужно или как он будет поддерживать их бизнес-модель. Чаще всего эти срочные запросы после доставки используются один или два раза и о них забывают. И однажды забытые, они становятся бесконечной головной болью дыр в безопасности и непредвиденных последствий.

Мне нравятся принципы:

1. QI - важно и срочно
2. QII - важно, но не срочно
3. QIII - не важно, но срочно
4. QIV - не важно и не срочно

1. Настройте систему отслеживания функций / ошибок / запросов и попросите своих клиентов / коллег подавать заявки. Если они не подают заявку на это, вы не делаете это. Билеты должны быть достаточно подробными, чтобы иметь возможность действовать, и должны указывать «срочность» («мне это нужно сейчас» против «приятно иметь»).
2. Пройдите новые билеты и тщательно оцените их. Введите стоимость в тикете в долларах, разработчиках, ресурсах и / или времени. Это важно . Когда ваши клиенты увидят, что на самом деле им что-то будет стоить, вы увидите очень разные варианты в поле «Срочность».
3. Ежедневно выясняйте свое расписание на основе поданных билетов и их срочности. Сделайте расписание видимым для других, чтобы было ясно, что вы делаете, и ваша готовность к будущим запросам.

Я видел проекты, в которых изменения требований управляются очень тяжелой системой контроля изменений. Это плохо. Множество важных изменений не происходит, потому что заказчик не хочет испытывать трудности с отправкой контроля изменений, поэтому программное обеспечение не соответствует его потребностям. Некоторые небольшие изменения добавляются «под радар», чтобы избежать процесса, поэтому программное обеспечение даже не соответствует тому, что вы думаете.

С другой стороны, я также видел проекты, в которых руководитель проекта считает «реагирующим» означает заставить кодеров отвечать на каждый запрос пользователей, а это просто означает, что вы никогда не завершите разработку ядра, а ваш код превратится в громоздкий беспорядок на вершине. хак. По сути, у вас сейчас нет разработчиков, у вас есть команда высококвалифицированных инженеров по продажам.

Таким образом, можно надеяться, что между этими двумя полюсами есть ситуация, которая работает хорошо, и я ожидаю, что то, что работает лучше всего для вас, это как личный выбор, так и расположение. Определенно стоит учитывать стоимость каждого изменения. В такой среде, как Scrum, вы можете выразить стоимость в баллах, и команда может обменять работу, которую они выполняют на каждой итерации, на общую доступную нагрузку. Если у вас есть менеджер по продукту, вы можете попросить этого человека оценить ожидаемую выгоду от запроса на изменение или функцию. Обычно это делается с точки зрения защищенного дохода (сколько клиентов уйдет, если вы этого не сделаете) и привлеченного дохода (сколько клиентов придет, если вы это сделаете). Это может помочь с установлением приоритетов, но также может отражать предвзятость или личные предпочтения менеджера по продукту.

Вот некоторые мысли ...

На рынке есть много программного обеспечения, которое вам поможет, http://www.fogcreek.com/ с Fogbugz, GeneXus USA с XPM http://www.genexususa.com/xpm и т. Д.

Это как искусство балансировать новые запросы функций с исправлениями ошибок и своими идеями. Вы должны получить еду на следующую зиму, но вы должны есть и сегодня.

У вас есть время, ресурсы и возможности, делайте все возможное из этого.

Генри Форд также однажды сказал: «Если бы я слушал клиентов, я бы дал им более быструю лошадь» ...

Лично: будьте динамичны, не ставьте правила, подобные тем, которые вы сказали ... и будьте осторожны с правилами других людей ... они могут хорошо работать в их контексте, но не в вашем.

В итоге мы пришли к тому, что теперь у нас будут двухмесячные встречи по продажам / проектированию, чтобы обсудить текущие проекты и будущие или будущие запросы на новые функции. Инженеры по продажам станут менеджерами проектов и, по крайней мере, будут в курсе последних предложений продуктов. Раньше было просто передать это Инжинирингу и забыть об этом. Это, вероятно, уменьшит нагрузку, которую должен сделать инженер-программист, и возложит ответственность за продажи и управление на то, чтобы разумно использовать наше время.

Компания, в которой я работаю, использует два основных приложения: веб-инструмент под названием JIRA для управления аспектами, связанными с проектом, и нашу систему справочной службы для обработки запроса на изменение с помощью функции rfc.

Ответы, которые я вижу до сих пор, хороши. Одна вещь, которую я конкретно скажу, заключается в том, что вам нужно уметь говорить «нет» на некоторые запросы.

Если вы позволите клиенту установить срочность, она почти всегда будет «высокой» (или большей).

Вы (или вы сами, или команда, в зависимости от ваших настроек) должны будете оценить эти запросы и расставить приоритеты на основе ваших собственных критериев.