26. Уточнення замовлення на проект.

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

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

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

(цього менеджера). Треба відмітити, що ситуація, коли замовник по-справжньому не уявляє собі відповіді на поставлені питання, - цілком типова, а тому в більшості реальних випадків

потрібний діалог між менеджером і потенційним замовником, уточнююче замовлення.

Найправильніше вести цей діалог так, щоб:

· спочатку зрозуміти, які завдання бажає вирішувати замовник за допомогою засобів,

що замовляються,

· потім запропонувати йому найбільш раціональний шлях рішення, здійсненний при

розміщенні замовлення у вашій організації.

В рамках цього діалогу головне, що треба зробити, - добитися однозначного розуміння використовуваних понять. Прямо заявити замовникові, що він в чому-небудь не правий, не

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

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

складову частину процесу ліквідацією двозначностей. Але тут є особливість, яка пов'язана з тим, що рішення завдань проекту має бути впорядковане в часі, і, як наслідок, необхідно

збудувати цю послідовність. При уточненні постановок завдань, передусім, необхідно з'ясувати, які з призначених для користувача завдань розглядаються як найбільш актуальних замовником. Можливо, що

замовник не структурує завдання зовсім, і тоді запропонувати відповідну структуру завдань проекту - справа менеджера, одержуючого замовлення.

Для аналізу відомостей про завдання проекту корисно виписати їх в порядку спадання пріоритетів у вигляді таблиці, що містить наступні поля:

· Найменування призначеного для користувача завдання;

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

або позначка про те, що рішення цієї задачі засобами виробу, що замовляється, фактично

не підтримується);

· Чого не вистачає для підтримки вирішення цієї задачі (зустрічні пропозиції, доповнення,

які доцільно включити в проект);

· Реалізаційні зв'язки між завданнями (реалізація засобів підтримки рішення одного із

завдань тягне реалізацію підтримки рішення іншій, засоби підтримки рішення обох

завдань мають загальні компоненти, завдання не пов'язані);

· Можливість локальної демонстрації рішення задачі (тобто такій демонстрації, яка не

залежить від рішення інших завдань). Якщо за цією ознакою завдання диференціюються

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

замовникові найскоріше. Доповните ними таблицю;

· Оцінка можливості використання доступного програмного забезпечення, зокрема,

напрацювань фірми, яка береться за виконання замовлення (корисно супроводжувати

таку оцінку вказівкою того, що саме передбачається використовувати). Якщо на те є

достатні підстави, то ці відомості можна не показувати замовникові;

· Оцінка вимог до кваліфікації розробників (порівняльна характеристика завдань);

· Попередній розподіл вартості розробки. Слід оцінити співвідношення трудомісткості

виписаних завдань і зразкові терміни їх рішення. У таблиці вказуються експертні оцінки

менеджера безвідносно вартості замовлення і обліком пропонованого фінансування

(друга позиція виставляється в ході аналізу таблиці). Процес заповнення цього поля може

викликати коригування переліку і змісту завдань проекту;

· Оцінка пріоритетності завдань. Вона виставляється в ході аналізу цієї таблиці.

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

критеріям відбору :

· мінімізація термінів демонстраційного рішення;

· переиспользуемость компонентів (колишніх розробок, наявних стандартизованных

модулів, а також що з'являються в ході розвитку проекту);

· істотність реалізаційних зв'язків;

· актуальність для користувача.

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

розбиту на дві частини, : найближчі завдання і перспектива, слід пред'явити замовникові. Було б непогано, переконати замовника, що додаткові завдання, що потрапляють в розряд

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

Результати аналізу в сукупності з їх мотивуваннями доцільно показати замовникові для досягнення угоди про проект. Зрозуміло, не слід вносити до документу, що пред'являється,

проміжні відомості (рішення, знехтувані самим менеджером, як неперспективні). Крім того, документ має бути максимально близький до пропозицій замовника. Пам'ятайте, що статус

його - уточнення замовлення, а не його трансформація в інше замовлення. Найбільш актуальним питанням, яке слід вирішити в найкоротші терміни, є угода про

найближчі завдання. Це пов'язано з двома обставинами. По-перше, час, який витрачається в передпроектний період, - це завжди витрати вашої фірми, а не замовника, а тому затягування

його просто невигідно. По-друге, тривала утруска спірних питань може натомити замовника, і тоді цілком реально говорити про те, що він віддасть перевагу над вами кому-небудь

іншого.

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

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

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

замовником з'ясовується, що запропоноване завдання може і за логікою речей повинно мати продовження. Це продовження не сформульоване явно і зовсім не обов'язково усвідомлено

замовником - він хоче вирішити конкретне завдання і тільки. Але менеджер розуміє, що:

· розумніше вирішувати загальнішу задачу і отримати що замовляється як один з

корисних наслідків;

· у замовника неминуче з'являться нові завдання, тісно пов'язані з першим замовленням;

· незалежно від фінансової привабливості замовлення можливе продовження обіцяє

відчутні вигоди (фінансування продовження цим замовником, накопичення досвіду,

можливість розвитку замовлення силами компанії та ін.);

· первинне замовлення дається, щоб випробувати майбутнього виконавця для перевірки

його потенційних можливостей.

Таким чином, перспективне замовлення - це та ситуація, коли розумно планувати комплекс робіт для послідовних завдань, готувати універсальні засоби підтримки, пропонувати замовникові

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

було б грубою помилкою менеджера до виконання першого завдання пропонувати замовникові фінансувати створення такого середовища. Єдина можливість отримати потрібні додатково ресурси -

це звернутися до керівництва фірми. Для перспективного з точки зору продовження замовлення може бути рекомендований наступний шлях виконання :

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

розглядається як прототип відробітку технології використання цього середовища;

· Розробка операційного середовища виділяється як самостійний проект, що виконується незалежно від першого завдання і паралельно з ним;

· Усі аспекти першого завдання і завдань, що продовжують замовлення, пов'язані з операційним середовищем, узгоджуються з нею по требумой функціональності і

інтерфейсам. Тобто демонструється здійсненність підходу, що розвивається;

· Завдання замовлення, що триває, виконуються в контексті використання результатів побудови операційного середовища.

Формування перспективного замовлення не обов'язкове в усьому дотримується представленої схеми. Цілком можливо, що замовлення усвідомлене як перспективний не

відразу, а в ході виконання першого завдання (на етапі оцінки) або після одного з наступних завдань. Це сигнал, що варто виробити ревізію напрацьованого і вирішити, доцільно або

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

переробки. В будь-якому випадку слід скорочувати термін ухвалення рішення, щоб мінімізувати витрати фірми. Може виявитися, що керівництво фірми вирішить залишити

інструментарій як власний (внутрішнього) продукт, іншими словами, не переносити його вартість на це замовлення. Це означає, що перспективність замовлення усвідомлена не з

фінансової точки зору, а як можливість розвитку потенціалу фірми.

27. Класифікація замовлень з точки зору документу “Заявка на проект”.

Конкурсне замовлення		Цільове замовлення
Особливості: • конкретний проект • конкурентний вибір виконавця		Особливості: • завдання може варіюватися • послідовний вибір виконавця
• фіксована форма заявки	• вільна форма заявки
Мета: підвищити	Мета: розширити круг	Мета: точніше встановити відповідність
об'єктивність при	відомостей, що оціню-	Проект-Внконавці
виборі виконавця	ються при виоорі
	виконавця