Давайте уявимо таку ситуацію: в молоду, ще не перевантажену компанію з розробки приходить запит оцінити проект. Замовник солідний, проект планується великий. Відразу виникає думка "Таке проґавити не можна - це і портфоліо, і досвід, і заробіток".
Замовник хоче, щоб йому дали оцінку. Оскільки проект об'ємний, щоб його правильно оцінити потрібно уточнити всі вимоги, розписати хоча б завдання і віддати експерту на оцінку. Сумарно це щільна робота на 1-2 тижні. А замовник чекати не буде. Тому вихід один: виставити приблизну ціну, а якщо говорити чесно, ціну "зі стелі". У підсумку замовник ще просить знижку. А на довершення вимагає ще й зафіксувати ціну проекту в договорі ("fixed-price").
Піддаючись спокусі роздобути замовника, Підрядник йде на це.
Дивіться відео: Методика оцінки на практиці і думка клієнта
Що ж буде далі?
Далі підрядник береться за роботу.
І виявляється:
І рішення всіх цих завдань потягне час, який не заклали в ціну, а ціна вже виставлена і навіть зафіксована.
В не менш цікавому положенні опиняється і керівник проекту на стороні замовника, адже всі рішення щодо проекту подаються і ухвалюються під його керівництвом. Жоден ТОП, який приймає фінансове рішення, не прорахує обсяг робіт за проектом, і тому це завдання покладається на проджект-менеджера. І що можна подумати, коли виявиться, що порахували не те і не так? Тут вже явне питання до компетентності і довіри.
Як ви думаєте, що керівництво компанії замовника легше прийме:
Питання довіри до партнера (як зовнішнього так і внутрішнього) - один з найважливіших факторів успішної співпраці.
Якщо після реальної оцінки бюджет зросте, у розробника є маса сценаріїв виходу з ситуації, і з них жодного позитивного:
В будь-якому випадку, від такої ситуації не виграє ніхто: підрядник втрачає і час, репутацію, і, можливо, фінанси.
Замовник ризикує отримати зірваний проект, даремно витрачений бюджет і негативне ставлення до розробників в цілому.
Ось так виграний за ціною тендер ще не гарантує успіху проекту.
Багаторічний досвід впроваджень наш і наших партнерів показує:
Це методика оцінки проекту або окремих завдань.
Після деталізації завдання проводиться 3 оцінки за завданнями або етапами проекту:
І замовнику бажано показувати всі 3 цифри, а не виставляти одну ціну. І в бюджеті теж потрібно оперувати всіма трьома.
Це дозволяє замовнику розуміти, що ціну не можна жорстко зафіксувати, і вона залежить від багатьох факторів: кількості робіт, ризиків, складності і глибини завдань. І все це може виявитися в процесі роботи. Не тому, що розробник так придумав, а тому, що це об'єктивні обставини предметної області.
Якщо будуть вимагати (так часто буває) фіксовану ставку або єдину ціну, її можна усереднено порахувати за формулою:
(1 хв + 4 серед + 1 макс) / 6
Насправді замовники, у яких є досвід впроваджень, а також ті, хто має фахівців достатньої кваліфікації, добре розуміють процеси ціноутворення доопрацювань.
В якості прикладу можна навести виступ представника одного з наших великих клієнтів, компанії Zeppelin, Євгенія Осьмака, Head of corporate IT.
Євген розповідає:
“Найбільша пастка для бюджету - це коли запитують оцінку, а потім роблять її зобов'язанням.
Якщо піддатися на таку тактику, то, отримавши досвід, розробник подальші свої оцінки множить на Пі (3,14).
І зворотна сторона такої вимоги в тому, що розробник взагалі перестає давати більш-менш чітку оцінку, називаючи терміни виконання завдання, наприклад, від 2 до 800 годин, не даючи затиснути його в будь-які рамки”.
Проект: у нього є час, раніше якого його не виконати.
Є ризики та ймовірності.
Є дуже маленька ймовірність того, що проект можна зробити за мінімальною оцінкою.
Досвідчений експерт оцінює задачу по-своєму, і така оцінка перевірена досвідом. На практиці ймовірність її дуже висока, оскільки вона ніби списана з життя.
І також є практична оцінка максимальної суми, яку доведеться витратити.
Всі ці три ціни важливо озвучувати замовнику - вони обґрунтовані, і такою інформацією можна оперувати.
Все інше - це ворожіння. Дати єдину правильну ціну - це як би вгадати наперед (передбачити) всі наслідки ризиків протягом терміну дії всього договору. Наскільки правдоподібно сподіватися на таке передбачення, починаючи проект?
За формулою оцінку можна усереднити, але ця середня ціна теж ні про що не скаже.
І чим довший термін проекту, тим вища ймовірність ризиків, відповідно, і ціна коливатиметься значніше.
І ще важливо уточнювати, яку оцінку замовник взагалі запитує. Може, він запитує песимістичну, тобто максимальну ціну, а ви йому повідомили "неймовірний мінімум", тоді проблемні ситуації неминучі.
Оцінку можна вважати точною, якщо вона не вийшла за межі мінімальної і максимальної ціни. А середнє значення зазвичай більше найбільш ймовірного, за експертною оцінкою, значення через хвіст.
Взагалі через напругу, яка створюється під час впровадження і відстоювання кордонів і цін не витримують навіть керівники проектів і залишають їх. А це втрати суттєві.
Ось таку думку висловлює фахівець з впровадження компанії Zeppelin. Повну версію виступу на CIO-Jazz-2018 можна подивитися тут >>>
Для прикладу ми вклали
наш шаблон оцінки проекту
скористайтесь ним.
Як це перевірити:
1) Отримали список завдань на оцінку. Може, ваші аналітики (фахівці) погодили такий список.
2) Його потрібно оцінити.
На перший погляд, є кілька завдань з докладним описом. І після ознайомлення можна дати інтуїтивну оцінку у 2-3 дні або 24-38 годин.
Часто так рахують.
3) Спробуйте порахувати за триточковою методикою.
Для цього переносимо завдання в наш файл. Розбиваємо їх на складові, а неподільні залишаємо як є.
І кожній проставляємо 3 оцінки.
4) Ще передбачаємо обов'язкові допоміжні роботи, додаємо % на:
За підсумками розрахунку ви побачите відчутну різницю в цифрах.
Часто замовник погано сприймає всю таблицю. Тому орієнтуючись на розуміння можна давати 3 оцінки або 2: мінімальну і середню.
Вирішувати, що показувати, в принципі, можна самостійно.
Але головне - ви для себе отримаєте інструмент для розуміння меж і ризиків.
Методологія підходить для детальних оцінок конкретних об'єктів і аналізу великих блоків, написання ТЗ. Формат деталізації можете вибирати самостійно: роботу можна записати одним рядком, а можна розбити на модулі ТЗ. І чим глибше ви підете в аналізі, тим якісніше будуть підсумки.
Навіщо і як проводити попередній аналіз проекту, дивіться в нашому відео (скоро на каналі).
Попит на автоматизацію з кожним днем зростає, і також збільшується кількість софтверних компаній. Можна подумати, що конкуренція зростає. Але на ринку насправді ми конкуруємо не з компаніями, рішеннями або якістю обслуговування, а із значно заниженими оцінками, відсутністю досвіду та методологічної бази оцінок, з оцінкою навмання.
Може здатися, що замовник виграє, але це ілюзія. Наслідки таких оцінок будуть поганими для всіх: і для розробника, що працює за зафіксованою ціною, і для замовника.
З одного боку, за заниженою ціною можна виграти тендер, але потім, прийшовши в 0, доведеться жертвувати якістю роботи, ставленням, репутацією і навіть проектом, який так хотілося отримати.
І як підтвердження вищесказаного, до нас часто приходять замовники після історії з "недобросовісним" підрядником, який завалив проект. Наша ціна їм подобається менше, але, навчені гірким досвідом, вони погоджуються на умови.
Ми обов'язково пояснюємо, чому оцінка - це завжди діапазон, і чому не можна фіксувати ціну.
У своїй компанії ми працюємо за моделлю time and material (T&M).
Щоб проводити професійну оцінку проекту, користуйтеся методологією.
Працюйте з вигодою!
Отримавши численні запитання і коментарі до відео з триточкової оцінки, ми вирішили дати відповідь на найчастіше "Звідки узята методологія?" деталі дивіться в нашому відео >>>
Читати статтю про стандарт PMI PMBoK 6th Edition >>>
Зосим Максим: Привіт всім! З вами Зосим Максим і команда tqm system.
Часто колеги по цеху запитують про методику оцінки проекту або окремих завдань. Саме цим я і хочу сьогодні з вами поділитися.
У своїй діяльності ми використовуємо триточкову оцінку. Як це працює? Після деталізації завдання ми робимо три оцінки по виконанню завдання або етапів проекту.
Власне кажучи, ми вважаємо, що потрібно показувати всі три цифри вашим замовникам. І апелювати в бюджеті потрібно не однією фіксованою ціною, а всіма трьома. Природно, клієнт може вимагати від вас (і скоріше за все буде) якусь фіксовану ставку, для чого можна усереднити оцінку, за допомогою формули: взяти 1 мінімальну + 4 середніх і + 1 максимальну і поділити це все на 6. Далі ми подивимося на прикладі, як це робиться.
А поки, що говорить про це один з наших великих клієнтів:
Євген Осьмак: Найбільша пастка бюджета наступна: це коли до людини приходять питать estimate, тобто оцінку, а потім в якийсь момент вона непомітно стає commitment, тобто зобов’язанням. Да? Тобто ще раз: поки воно estimate – все добре. Як тільки воно стає commitment, перший раз в житті, да? Наступний раз ІТ-шник що обере? - estimate помножить на π. Точніше досвідчений на π, не досвідчений на е. Ну правильно? – це ж математика.
Євген Осьмак: Там два множника: е – 2,76 і π – 3,14. Все решта – то не наукове. Не треба - Нє, дивіться… як я вирішую цю проблему з commitment(ами) і estimate(ами), да? Інакше просто якщо ми прив’язуємо commitment до estimate – ти з експерта нічого не виб’єш. Він просто стає в жостку опозицію, починає видавати там… не знаю.. від 2х до 800 годин оцінку. Скільки задача займе? – від двох до 800 годин. Ну тобто це називається пасивна агресія. Розумієте, да? Ну точніше це навіть не пасивна.
Є поняття трьохточечної оцінки. Трьохточечна оцінка. Графік ймовірності виглядає таким чином.
У бідь-якого проекта значить є: мінімальний час, за який його можна зробити. В принципі мінімальний. Дев’ять жінок за місяць не зроблять одну дитину. Оце так пояснюю – всі розуміють. Тобто є мінімальний час за який.. менше якого не можливо цей проект зробити. От ніяк. От тут це наймолюсінька можливість, що якщо все буде добре і все ні одної проблеми, і всі… попутній вітер – то це перший там… це може бути або час, або гроші – не важливо. Нехай це будуть гроші.
Тепер, що тут ще є: тут є найбільш ймовірне значення. Його особливість в тому, що його відчувають експерти. Експерт інтуїцією своєю, накопиченим досвідом… Коли, за скільки зробиш? - ві задає оце найбільш ймовірне значення. Розумієте? Він відчуває. Ох, два дні.
Голос із залу: По осі y - це ймовірність?
Євген Осьмак: Да, да, да. Це ймовірність, що будуть… в результаті такі зусилля. З часом механіка така сама.
Голос із залу: Частки там? 0%, 100%
Євген Осьмак: Ні, ні, ні. Це є розподіл… інтеграл оцього 100%. А це функція щільності-ймовірності. Нє? Ну… Окей. Це звичайна ймовірність. От тут, наприклад, 20%, тут – 19. Якщо всі оціі скласти, то получиться 100. Це означає, що в даному випадку, отак на око, ймовірність 25%, що буде оця точка. Ну я не знаю… І є третя точка - це з дуже великою ймовірністю, наприклад, з ймовірністю 95% - це не займе більше ніж.
Таким чином ми маємо: оптимістичний, в середньому і песимістичний… значення. Я всі три показую. Я бізнесу три показую. Прям три. Я говорю: от дивіться, оптимістичний прогноз – буде 10 тисяч доларів, але він неможливий, песимістичний – 16, експерти думають – 14 і робіть з цим що хочете. Ще раз, це та інформація надійна, яку я можу дать. Я що оракул, що знаю скільки вона буде стоїть?! Я що буду когось обманувать?! Я що ведун?! Якщо люди шукають чарівників – вони находять казкарів – це ж очевидно. Якщо людина шукає оракула дельфійського – вона знаходить…
У нас був… знаєте увійшов в фольклор фразой: at basically everything is possible. Можна це зробити? – basic. А там по англійськи у нас просто, проект був англомовно. is it possible – basically everything is possible. Молодец! Вот ето! Як ми тебе чекали. А знаєте до чого потім… Значить, дивіться у нас вже обговорення і режим afterparty. От є життєвий цикл продукта, є життєвий цикл проекта, а є життєвий цикл ПМ(а) проекта. Ну… Тобто, печаль наступає тоді коли… ось тут - basically everything is possible, а потім життєвий цикл ПМ(а) короче чем у проекта. Тому що от тут десь наступає фаза терморектального криптоаналізу… ну прочитаєте на цьому… на Lurkmore про терморектальний криптоаналіз, ну ви розумієте.
Голос із залу: Тут всі ІТ-шники.
Євген Осьмак: Коли питають доколе, почем і так далі. Головне от тут піти на підвищення у цей момент.
Голос із залу: Хороший спосіб.
Євген Осьмак: Так працює. Я не пробував, но я бачив як це працює, прям в реалє.
Фрагмент фільму: I believe I can fly, I believe I can soar. I believe I can fly. I believe! I believe! I believe! I believe!
Євген Осьмак: Із-зі цього я даю бізнесу таку трьохточечну оцінку по будь-якій задачі, яка крупна. І говорю, що… є думка, якщо вжити таку формулу: (мін+4*серед+макс) / 6. Математика нічого кращого ніж це не придумала. Тобто якщо вам треба одна оцінкка, то вона ні о чом, но можете взяти таку формулу. Нічого кращого немає. Но воно все рівно ні о чом. Тобто ще раз, коли вони мене починають кальоним залізом видавлювать одну цифру, я їм говорю, тільки це ні в якому разі не commitment(не) – це по перше. По друге, от де я її взяв, от… і це ширше оце… Тобто дивіться, оцей чим він вужчий – тим більше експерт впевнений що ризики не великі. Чим ця штука ширша… в перший раз у бізнесах, це викликало яку-то таку роботу думки всередині. Зараз вони не уявляють по іншому. Це 7 років так працювали. Розумієте?
Це я їм приніс. Ребята, я не чарівник. От є мінімальний, він неможливий. Ну хочете… Знаєте яка ще єсть небезпека? – бізнес питає: за скільки зробите? Ну ви ж не знаєте, яка з цих трьох точок його цікавить. Надійна оцінка чи оптимістична. А ви не знаєте. Якщо ви не запитали, може бути така небезпека: він питав про оцю (максимальна), а ви йому відповіли оцю (мінімальна). Із-за цього будь в якому випадку, коли результуючий проект закінчується от тут (між експертною оцінкою і максимальною), да? Ми говоримо: ну все хорошо, пішов трохи песимістичний сценарій, ми вклались в свою оцінку, значить ми молодець. Да? Тобто ми регулярно міряємо на скільки ми попадаємо в цю оцінку. Якщо ми з нею починаємо вивалюватися, значить ми лохи. Понімаєте? Ми не розуміємо вообще то чим займаємося і вон із професії. Якщо ми попадаєм, да?... Більше того, тут же основний дзен полягає в тому що найбільш ймовірне значення відрізняється від медіани. Бо в середньому буде оттак. Із-за хвоста, розумієте? То есть середньому виходить більше, ніж говорять експерти. Із-за того всі розуміють, що його треба множити. Тільки ніхто не знає на скільки. На π чи на е.
Зосим Максим: Якщо ви не хочете показувати це відео, що логічно, тобто окремий повний виступ Євгена на каналі спільноти IT-директорів. Посилання буде в описі. І в принципі рекомендую переглянути всі відео. Там маса корисної інформації для розуміння того, як IT має взаємодіяти з бізнесом.
Але варто пам'ятати іншу сторону оцінок, коли ви підписуєте з клієнтом на фікс-прайс – ви змушені закладати в оцінку кожної задачі ризики пов'язані з рівнем розробника, технічною складністю та іншими складовими розробки проекту.
Давайте розберемо простий приклад, а також інструменти використання методології. Наприклад, клієнт надсилає вам список завдань, у вигляді декількох файлів із завданнями. Або припустимо, що це ваші фахівці узгодили ці завдання і їх необхідно оцінити. На перший погляд є кілька завдань з докладним описом. І якщо ви або ваш фахівець ознайомитися з ними, то інтуїтивно (це я по собі можу судити) ця оцінка буде 3-4 дні або від 24 до 32 годин. Часто саме так і чинять партнери.
Але давайте проведемо аналіз цього документа за допомогою інструменту триточкової оцінки. І не одним рядком, а розкладемо на складові завдання. Беремо кожну задачу з тексту файлу і копіюємо її в наш файл. Якщо завдання неподільне, ми так його вставляємо. Якщо його можна розбити на частини, то ми ділимо його і уточнюємо деталі для кожного рядка. Далі, для кожного рядка, ми проставляємо оцінку: мінімально можливу, середня на думку експерта та максимальна за яку завдання не повинно вийти за всіх поганих розвитку подій. В кінці файлу ми додаємо відсоток для тестування, координацію і планування від усіх завдань. І якщо клієнт новий-то час на розгортання тестової інфраструктури: бази, сховища, доступ і так далі. У підсумку ви бачите відчутну різницю в цифрах.
Якщо вам ліньки робити шаблон, то можете завантажити його за посиланням в описі, замінити на своє лого, але врахуйте, що багато клієнтів погано сприймають всю таблицю. Тому в залежності від клієнта, ми показуємо всю таблицю, або три оцінки, або мінімальну усереднену, в рамках комерційної пропозиції. Ну або ж надаємо клієнту обома файлами. Зрештою, ви самі можете вирішити, які цифри показувати і яку методологію оцінки озвучувати вашому клієнту. Головне, що у вас з'явитися інструмент і розуміння можливих кордонів і ризиків.
Сама методологія підходить як для детальних оцінок, конкретних об'єктів, так і для аналізу великих блоків. Наприклад, написання технічного завдання. Можна зробити це як одним рядком, так і розбивши на необхідні модулі самого ТЗ. Пам'ятайте, чим нижче ви опуститеся в аналізі – тим якісніше вийде синтез підсумкових значень.
Можливо, у вас виникло питання: навіщо ми це робимо? Відповідь проста. Останнім часом ми конкуруємо з іншими продуктами або якістю обслуговування клієнтів. Ми все більше конкуруємо з конкретною ціною. А конкретніше з неправильною оцінкою з голови у початківців партнерів або відсутнім досвідом і не маючи якої-небудь більш-менш зрозумілою методології оцінки, ми просто стикаємося з оцінками навмання і сильно заниженою вартістю для клієнта. Це призведе до поганих наслідків, як для клієнта, так і для партнера. Особливо для тих, хто працює за фіксованою моделлю. З одного боку, за ваші оцінки ви виграєте тендер. Але з іншого, при неправильній оцінці ви в підсумку працюєте в нуль. І вам доведеться жертвувати, або якістю виконання робіт, піддаючи ризикам подальшу працездатність вашого коду. А якщо ви сильно підете в мінус, то і з клієнтом доведеться пояснювати. Або пояснювати чому він повинен доплачувати. Або ви спробуєте закласти і ризики, і витрати на такі роботи, що в результаті сформує негативне ставлення, як до вас, так і до інших партнерів.
Ми вже не раз стикалися з ситуацією і відгуками клієнтів і довго пояснювали чому оцінка завдання – це завжди діапазон. І чому не можна працювати за фіксованою ставкою. Саме тому ми в нашій компанії працюємо за моделлю time and material.
Так що, якщо ви хочете показати клієнту більш реальну картину, використовуйте методологію триточкової оцінки або довільну на підставі її. Або будь-яку іншу.
До речі, якщо у вас є цікаві кейси, як ви оцінюєте, діліться ними в коментарях.
Аналізуйте, оцінюйте та працюйте з вигодою.
Не забувайте підписуватися на канал і ставити дзвіночок.
Скоро буде ролик про необхідність і структуру етапу експрес обстеження в проектах.
Дивіться повне відео Триточкова оцінка >>>
*Копіювання матеріалу можливе тільки з посиланням на джерело та із зазначенням автора матеріалу. Дякуємо за повагу інтелектуальних прав власності. TQM systems
Видео про ключові моменти впроваджень систем автоматизації на каналі TQM systems: кейси, методики роботи, нові розробоки та можливості.
SaaS сервіси
Програми 1С:Підприємство
CRM
ERP
Node.JS, .NET
1С:Підприємство
API, IPasS
Разработка Web Apps
1С:Підприємство Автоматизація
Аудит IT проектів
Інтеграція 1С:Підприємство
Отримуйте наші інформаційні матеріали:
Працюємо на IT-ринку з 2008 року.
Наша місія - спростити управління даними.
Copyright © 2008-2024 TQMsystems. Всі права захищені. Privacy Policy | Terms of Service