Менеджмент у сфері програмного забезпечення

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

Життє́вий цикл това́ру — час, упродовж якого товар життєздатний на ринку і забезпечує досягнення цілей продавця. Від життєвого циклу товару залежить рівень прибутку на кожній із його стадій:

• Впровадження товару на ринок;
• Зростання обсягу продажу внаслідок визнання товару покупцями;
• Стадія зрілості, яка характеризується максимальною прибутковістю;
• Спад обсягу продажу і прибутку.

• Розробляти стратегію управління не тільки з-погляду прибутків, але й цінності для споживача
• Займатися тим продуктом, який справді є цінним (тобто ви самі насправді вірите в його цінність), тоді легше здійснювати ефективне управління
• Глибоке знання ринку на якому працюєш, особливостей клієнтів і особливостей даного продукту
• Періодично перевіряти свій внесок до збільшення продажу продукції, та максимізації прибутку
• Правильно оцінити всі ризики
• Створення максимальної цінності з мінімальною витратою ресурсів (lean технології)
• Налагодження ефективної командної роботи: чіткий розподіл завдань і контроль за їх виконанням
• Комунікабельність, зовнішність, поведінка

У рамках цих п'яти етапів існують наступні особливості програмного менеджменту:

• Розроблення ідеї нового програмного продукту, або наступної версії існуючих продуктів.
• Збір пріоритетів і вимог конкретного бізнесу та ринку залежно від спрямування розробки, побажань клієнтів щодо більш ранніх версій продукту, побажань експертів-науковців предметної області, прогнозів щодо розвитку ринку, продуктів і послуг від конкурентів і т.д.
• Розробка проекту вимог до продукції і проекту ринкових вимог які синтезують вимоги / потреби різних зацікавлених сторін. Проект ринкових вимог (market requirements document,MRD) - документ, що показує бажання та потреби клієнтів щодо послуги чи продукту. Проект повинен пояснювати: чому цей продукт потрібен; хто цільова аудиторія; які продукти є конкурентними до нього, і чому покупці оберуть саме його? Проект вимог до продукції (product requirements document, PRD) являє собою документ, який визначає якісні характеристики нового продукту, який вони роблять, або нові вимоги чи нові можливості для існуючого продукту. Проект вимог до продукції часто створюється після того, як було написано проект ринкових вимог і було дано отримано згоду керівництва на розробку. Як правило, він створюється до проекту технічних вимог до продукту (або принаймні одночасно). Він призначений, щоб людям всередині компанії було зрозуміло, який це повинен бути продукт, і як він повинен працювати. PRD найчастіше використовується для створення програмних продуктів, але може бути використаний для будь-якого виду продукції. Він є результатом аналізу вимог різних категорій користувачів та експертів. PRD повинен визначити проблеми, які будуть вирішені завдяки створенню продукту (або нових функцій продукту), але слід уникати описання технічного рішення цих проблем. Таке уникнення потрібне, щоб при розробці технічних вимог до продукту вже кваліфіковані інженери використовували свої навички, щоб створити оптимальне рішення для вимог, визначених у PRD. Іноді проект вимог до продукції слугує одночасно проектом ринкових вимог. Особливо, якщо продукт є невеликим або не складним для розроблення. Типові компоненти проект вимог до продукції: назва та інформація про автора; призначення та область застосування, як з технічної і комерційної точки зору; вказування зацікавлених сторін; оцінка ринку і цільової аудиторії; огляд продукту та прикладів використання; огляд характеристик (функціональні характеристики;технічні показники;екологічних характеристики;умови обслуговування користувачів вже після продажу;взаємодія з іншими програмними продуктами);обмеження(терміни та етапи розробки); план оцінки продукту та показники ефективності

• Організація злагодженої роботи між відділом управління, відділом продажів і відділом розробки програмного забезпечення. Передання зрозумілого проекту вимог до продукції до відділу розробки програмного забезпечення.
• Після того як програмний продукт потрапляє в цикл розробки, проведення додаткових випробувань продукції.
• У компаніях, що займаються високими технологіями, система менеджменту трохи відрізняється. Менеджер з продукції (Product Manager) аналізує характеристики майбутнього продукту на основі даних продажів, та думок експертів, і створює проект вимог до продукції (PRD), який буде використаний технічним відділом для створення продукту. У той час, як менеджери з маркетингу продукції (Product Marketing Managers) можуть займатися створенням проекту ринкових вимог (MRD), який використовується як джерело для розробки PRD. В інших компаніях менеджер з продукції створює обидва проекти, в той час як менеджер з маркетингу продукції відповідає за поточні завдання. А також створення маркетингових матеріалів, таких як короткові довідкові матеріали (cheat sheets); брошури даних (специфікації, data sheets) – містять докладні технічні характеристики; і білі книги (white papers) – довідковий матеріал, що включає окреслення проблемної ситуації, які вирішує даний продукт, та обґрунтування, чому даний продукт вирішує її краще, ніж інші. У невеликих високотехнологічних фірм (start-ups) обидві посади часто поєднує одна людина. Тим не менше, у міру зростання компанії практика показує, що в управління програмним продуктом ефективнішим є розділення функцій. Хтось повинен зосередитися на створенні зрозумілих проектів вимог до технічного відділу, в той час як інший зосередити увагу на правильному аналізі ринкових тенденцій. У Силіконовій Долині складається тенденція, коли наймається один менеджер з маркетингу продукції на групу продукт менеджерів.
• Інша риса всього управління високотехнологічних фірм, і тих, що займаються програмним забезпеченням, що менеджери з продукції та маркетингу продукції, крім навичок менеджменту та маркетингу, мають глибокі технічні знання. Набирає обертів популярності термін менеджер з технічного маркетингу (technical marketing manager). Технічні знання стають все більш цінними, оскільки компанії все більше конкурують, і прагнуть скоротити витрати
• Пошук клієнтів для постачання продукції. Це може бути рекламування продукту для клієнтів через різні веб засоби, створення демо версій продукт, та інші промо тактики. Але у Силіконовій долині найчастіше застосовуються саме дві, вище згадані. Рідше використовують стратегії щодо ціни.
• Після здійснення купівлі повинен бути налагоджений зворотний зв'язок з клієнтами, щоб вони змогли вчасно повідомляти про помилки та проблеми програмного забезпечення, а менеджер передавав їх для подальшого удосконалення. Так само слід менеджер повинен слідкувати за думками експертів, і передавати їх до технічного відділу.
• Слід проводити аналіз конкурентного середовища даного продукту, наскільки успішно він конкурує з іншими схожими продуктами. Так само корисно отримати інформацію про переваги та недоліки про конкурентний продукт, як від звичайних користувачів так і від експертів, та передавати їх до технічного відділу.

Важливим аспектом управління програмним продуктом є правильна пріоритетность удосконалень. Методика Джоел Спольскі (колишній менеджер з програми Microsoft Excel) вважається однією з найефективніших:

• Визначити авторитетність думок, і створити тестову групу
• Скласти список всіх елементів удосконалень
• Оцінити зусилля, необхідні для покращень (в часі та у грошах)
• Додати всі зусилля, назвемо цю суму E (efforts)
• Кожен із членів групи визначає пріоритетність. Кожному з них дається величина 0,5 × E, яку вони повинні витратити на різні елементи удосконалень відповідно до вподобань. Обмежень не існує, в тому числі можна витрачати всі зусилля на один елемент.
• Далі відбувається ранжування елементів на основі суми оцінок
• Впроваджуються всі поліпшення з дотриманням послідовності настільки дозволить фактичний бюджет