Як ви керуєте запитами функцій та змінами програмного забезпечення? [зачинено]

Я - інженер програмного забезпечення, і за останні кілька років я став менеджером програмного забезпечення де-факто просто тому, що його немає. Тож, щоб зберегти нашу розумність у відділі досліджень та розробок / інженерії, клієнти звикли звертатися до мене зі своїми проханнями. Я не маю досвіду в цій царині, тому вперше я виступаю менеджером проектів програмних проектів. Я керував іншими речами, але не програмним забезпеченням.

Отже, як ви керуєте програмними проектами та визначаєте пріоритети? Запити надходять з нечастою інтервалом, тому ми дуже добре можемо працювати над чимось іншим, і тоді інша людина приходить із "поспіхом" роботою, над якою потрібно працювати. Чи простіше просто сказати "Перший прийшов", "Перший сервіс" чи це людина, яка має найбільше грошей?

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

Зазвичай я класифікую запити в цьому порядку (YMMV):

1. Проблеми, пов’язані з недавнім оновленням або міграцією (найважливіше).
2. Виправлення безпеки.
3. Порушена функціональність існуючої системи.
4. Порушена функціональність у функціях RC та beta.
5. Платні запити на функції.
6. Запроси на НДДКР з боку значної частини бази користувачів.
7. Запроси на НДДКР лише від одного або двох користувачів.

Цей останній насправді займає набагато більше часу, тому що вони, як правило, є тими "терміновими, мені це потрібно вчора". Насправді користувач рідко повністю замислюється над тим, що їм насправді потрібно або як це підтримуватиме їх бізнес-модель. Найчастіше ці невідкладні запити, щойно доставлені, в кінцевому підсумку використовуються один раз або двічі і про них забуваються. І колись забуті, вони стають нескінченним головним болем у дірках безпеки та ненавмисними наслідками.

Мені подобаються принципи:

1. QI - важливі та термінові
2. QII - важливий, але не терміновий
3. QIII - Не важливо, але терміново
4. QIV - не важливо і не терміново

1. Налаштуйте систему відстеження / помилок / запитів та запросіть своїх клієнтів / колег подати квитки. Якщо вони не подають на нього квиток, ви цього не робите. Квитки повинні бути досить деталізованими, щоб вони могли діяти, і вони повинні вказувати "терміновість" ("мені це потрібно зараз" проти "приємно мати").
2. Перегляньте нові квитки та ретельно розширюйте їх. Введіть вартість квитка в доларах, розробниках, ресурсах та / або часі. Це важливо . Коли ваші клієнти побачать, що щось дійсно їм коштуватиме, ви побачите дуже різний вибір у полі "терміновості".
3. Щодня визначайте свій графік на основі поданих квитків та їх терміновості. Зробіть графік видимим для інших, щоб було очевидно, що ви готові, і ваша доступність для майбутніх запитів.

Я бачив проекти, де зміни вимог регулюються дуже важкою системою контролю змін. Це погано. Багато важливих змін не трапляються, оскільки замовник не хоче переживати клопотання щодо подання контролю змін, тому програмне забезпечення не відповідає їх потребам. Деякі невеликі зміни потрапляють "під радари", щоб уникнути цього процесу, тому програмне забезпечення навіть не відповідає тому, що ви думаєте.

І навпаки, я також бачив проекти, де керівник проектів думає, що "реактивний" означає змусити кодери відповісти на кожен запит користувачів, а це просто означає, що ви ніколи не зробите жодної основної розробки, а ваш код стає великим неприємним хаосом. рубати. По суті, у вас зараз немає розробників, у вас є команда інвалідів з продажу кваліфікованих кадрів.

Тож можна сподіватися, що між цими двома полюсами є ситуація, яка працює добре, і я думаю, що те, що найкраще працює для вас, - це і особистий вибір, і розміщення. Однозначно важливо враховувати вартість кожної зміни. У такій структурі, як Scrum, ви можете виразити вартість у сюжетних точках, а команда може торгувати роботою, яку вони виконують, за кожну ітерацію, порівняно із загальним наявним зусиллям. Якщо у вас є менеджер продукту, ви можете змусити цю людину оцінити очікувану вигоду від запиту на зміни чи функції. Зазвичай це робиться з точки зору захищеного доходу (скільки клієнтів залишило б, якщо ви цього не зробили) та залученого доходу (скільки клієнтів прийде, якщо ви це зробите). Це може допомогти у встановленні пріоритетності, але також може просто відображати упередженість або особисті переваги менеджера продукту.

Ось кілька думок ...

На ринку є багато програмного забезпечення, яке допомагає вам, http://www.fogcreek.com/ з Fogbugz, GeneXus США з XPM http://www.genexususa.com/xpm тощо.

Це як мистецтво балансувати нові запити на функції за допомогою виправлень помилок та власних ідей. Ви повинні отримати їжу на наступну зиму, але їсти доведеться і сьогодні.

У вас є час, ресурси та сфера, ви можете зробити все, що можна зробити.

Генрі Форд також одного разу чудово сказав: "Якби я слухав клієнтів, я б дав їм швидшого коня" ...

Особисто: будьте динамічні, не ставте такі правила, як ви сказали ... і будьте обережні з правилами інших людей ... вони можуть добре працювати в їхньому контексті, але не у вашому.

Що ми нарешті придумали, це те, що зараз ми матимемо щомісячні зустрічі з продажу / інженерії для обговорення поточних проектів та майбутніх чи майбутніх запитів на функції. Інженери з продажу стануть менеджерами проектів, і принаймні вони будуть співзвучні останнім пропозиціям продукції. У минулому просто було просто передати його інженерії та забути про нього. Це, швидше за все, зменшить навантаження, яку повинен виконати інженер програмного забезпечення, і покладе на себе відповідальність за продаж та управління, щоб розумно використовувати наш час.

Компанія, для якої я працюю, використовує два основні програми, веб-інструмент під назвою JIRA для обробки аспектів, пов'язаних з проектом, і наша система довідкової служби для обробки запиту на зміни через функцію rfc

Відповіді, які я бачу поки що, хороші. Одне, що я конкретно промовчу, це те, що вам потрібно буде добре сказати "Ні" на деякі запити.

Якщо ви дозволите клієнту встановити терміновість, він майже завжди буде "Високий" (або більше).

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