Менеджмент у сфері програмного забезпечення Цю статтю треба вікіфікувати для відповідності стандартам якості Вікіпедії Б

Менеджмент у сфері програмного забезпечення( англ. Software product management) являє собою сукупність процесів управління даним продуктом на різних його стадіях, тобто на різних етапах життєвого циклу товару, і з врахуванням інтересів користувачів продукту. Це наука і бізнес-процес водночас, як правильно здійснювати управління у галузі від початку виникнення потреби у продукті і до постачання його на ринок, та обслуговування клієнтів з метою отримання максимальної цінності та значення для бізнесу.

Продукти програмного забезпечення ред.

Програмний продукт, яким займається даний вид менеджменту призначений для використання багатьма користувачами, наприклад підприємствами. Саме це відрізняє даний вид діяльності від IT-консалтингу, сфери консалтингу, що вказує, як краще використовувати інформаційні технології для потреб певного сектора бізнесу. Програмне забезпечення в сфері якого здійснюється IT-консалтинг використовується обмеженою, невеликою кількістю користувачів. Відомі IT-консалтингові фірми, як IBM Global Services та Accenture.

Приклади продуктів програмного забезпечення для бізнесу включає базу даних Oracle 10g database, розроблену Oracle Corporation, SAP R / 3 ERP програму, розроблену SAP AG, QuickBooks від Intuit та інші.

Іншими приклади споживчих товарів програмного забезпечення є Microsoft Office від Microsoft, TurboTax^[en], розроблений фірмою Intuit. З кінця 1990-х років, багато програмних продуктів розроблялися так, що клієнти могли здійснювати запуск програми без установки програмного забезпечення на своїх комп'ютерах. Приклади: Customer Relationship Management (CRM) програма від Salesforce.com, програмного забезпечення від Shopping.com для порівняння якостей і цін товарів, різних інструментів вебпошуку, пропонованих Google, Yahoo!, аукціон eBay. Навіть якщо ці програми є додатками інших програм, тим не менше, вони вимагають не менш серйозного управління продуктом. Особливо в сфері доступу до послуг і прав користування.

Потреба у програмному менеджменті ред.

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

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

Роль менеджера програмного забезпечення ред.

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

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

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

Зміст управління продуктом програмного забезпечення ред.

Управління програмного продукту охоплює всі етапи від моменту створення продукту до його кінця його використання. Відповідно до основних стадій життєвого циклу продукту розроблено етапи менеджменту:

Стратегія загального розвитку певного напряму
Концепція розробки конкретного продукту
Вихід на ринок
Подальший розвиток проекту
Еволюція продукту

Особливості програмного менеджменту ред.

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

Розроблення ідеї нового програмного продукту, або наступної версії існуючих продуктів.
Збір пріоритетів і вимог конкретного бізнесу та ринку залежно від спрямування розробки, побажань клієнтів щодо більш ранніх версій продукту, побажань експертів-науковців предметної області, прогнозів щодо розвитку ринку, продуктів і послуг від конкурентів і т.д.
Розробка проекту вимог до продукції і проекту ринкових вимог які синтезують вимоги / потреби різних зацікавлених сторін. Проект ринкових вимог (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, яку вони повинні витратити на різні елементи удосконалень відповідно до вподобань. Обмежень не існує, в тому числі можна витрачати всі зусилля на один елемент.
Далі відбувається ранжування елементів на основі суми оцінок
Впроваджуються всі поліпшення з дотриманням послідовності настільки дозволить фактичний бюджет

Посилання ред.

↑ Christof Ebert (2009). "Software Product Management" [ 31 жовтня 2012 у Wayback Machine.] in: Crosstalk, Vol. 22, No. 1, pp. 15-19, Jan. 2009.
Christof Ebert (2007). "The Impacts of Software Product Management" in: The Journal of Systems and Software. ISSN 0164-1212, Volume 80, Issue 6, pp. 850-861, June 2007

Kittlaus, Hans-Bernd (2009). . Springer. ISBN 3540769862. Архів оригіналу за 29 вересня 2012. Процитовано 5 грудня 2012.
Conde, Dan (2002). Software Product Management: Managing Software Development from Idea to Product to Marketing to Sales (Execenablers). Aspatore Books. ISBN 1-58762-202-5.
Dver, Alyssa S. (2003). Software Product Management Essentials. Anclote Press. ISBN 0-929652-01-0.

Зовнішні посилання ред.

International Software Product Management Network [ 27 жовтня 2021 у Wayback Machine.]
Software Product Management Twiki and Resources [ 18 квітня 2012 у Wayback Machine.]
International Workshop on Software Product Management (IWSPM) Series [ 6 серпня 2010 у Wayback Machine.] IWSPM 2010 [ 5 серпня 2010 у Wayback Machine.]

[Ebert09-1] Christof Ebert (2009). "Software Product Management" [ 31 жовтня 2012 у Wayback Machine.] in: Crosstalk, Vol. 22, No. 1, pp. 15-19, Jan. 2009.

[Ebert07-2] Christof Ebert (2007). "The Impacts of Software Product Management" in: The Journal of Systems and Software. ISSN 0164-1212, Volume 80, Issue 6, pp. 850-861, June 2007