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

21

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

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

Брайан
источник
1
проверить это: programmers.stackexchange.com/questions/874/…
luis.espinal
1
и, возможно, это также: programmers.stackexchange.com/questions/3747/…
luis.espinal
1
Я использую лозунг Нэнси Рейган: «Просто скажи НЕТ!» Шутки в сторону. Никогда не совершайте ничего на месте. Это один из способов, с помощью которого инженеры-программисты сталкиваются с большими проблемами. Очень важно противостоять принятию случайных обязательств или даже оценке того, является ли что-то «сложным» или «легким». Всегда откладывайте решение, а затем примите несколько прекрасных советов, которые появятся в ответах. Ваша репутация зависит от того, сможете ли вы выполнить свои обязательства - и она сильно ухудшится, как только вы сделаете слишком много обязательств.
Анджело

Ответы:

21

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

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

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

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

Майкл Дж. Сабал
источник
3
Ваш профессор может захотеть спуститься с Башни Слоновой Кости на некоторое время.
Джеффо
6
Он имел в виду, что многие люди позволили всем отвлекающим факторам, требующим нашего немедленного внимания, помешать нам сосредоточиться на тех вещах, которые действительно важны. Это было несколько лет назад, поэтому его примером был телефон. Всякий раз, когда он встречался со студентом, он помещал свой телефон прямо в голосовую почту. Я нашел это отличным заявлением о целостности и эффективности.
Майкл Дж. Сабал
4
Ага, платящие клиенты получают более низкий приоритет, чем бета-функции ?
JBRWilkinson
12

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

  1. QI - важно и срочно
  2. QII - важно, но не срочно
  3. QIII - не важно, но срочно
  4. QIV - не важно и не срочно
Adamizer
источник
Откуда это?
Ладья
Перво наперво (1994) является самопомощи книга , написанная Стивеном Кови и А. Роджером и Ребекка Р. Меррилл en.wikipedia.org/wiki/First_Things_First_%28book%29
Adamizer
@Rook - также в списке «7 навыков высокоэффективных людей» Кови. Отличная книга.
Неми
6
  1. Настройте систему отслеживания функций / ошибок / запросов и попросите своих клиентов / коллег подавать заявки. Если они не подают заявку на это, вы не делаете это. Билеты должны быть достаточно подробными, чтобы иметь возможность действовать, и должны указывать «срочность» («мне это нужно сейчас» против «приятно иметь»).
  2. Пройдите новые билеты и тщательно оцените их. Введите стоимость в тикете в долларах, разработчиках, ресурсах и / или времени. Это важно . Когда ваши клиенты увидят, что на самом деле им что-то будет стоить, вы увидите очень разные варианты в поле «Срочность».
  3. Ежедневно выясняйте свое расписание на основе поданных билетов и их срочности. Сделайте расписание видимым для других, чтобы было ясно, что вы делаете, и ваша готовность к будущим запросам.
Евгений Брикман
источник
+1 за отслеживание проблемы. Я должен был сделать это с коллегами раньше. Я говорю им, если это действительно так важно для меня, это должно стоить 5-10 минут, которые потребуются им, чтобы подать билет.
до
3

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

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

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


источник
2

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

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

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

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

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

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

Армин Бахманн
источник
2

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

Брайан
источник
1

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

GrumpyMonkey
источник
1

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

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

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

Вонко вменяемый
источник