Як я можу оцінити проекти, коли мені потрібно включити криву навчання нової технології?


11

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


5
Візьміть будь-яку оцінку за відомою технологією та перенесіть на десяткове місце: P
Rig

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

1
@MichaelT - чудовий коментар. Єдине, що гарантує зробити неточні оцінки більш приємними - це їх уточнення з часом, щоб керівництво отримувало все більш точну оцінку роботи, що залишилася. Єдине, що гарантовано розіб'є їх - це проект, який знаходиться назавжди за два тижні від завершення.
Carson63000

Це те, для чого призначені прототипи.

@ Carson63000 У мене була спрощена версія конусу невизначеності в цьому фразуванні. Ключове, що слід відібрати від цієї ілюстрації, - це те, що оцінка за 2-12 місяців не означає, що вона закінчується в кінці 7 місяців, а, скоріше, оцінка може збігатися від 2-12 до 4-12 до 8-12 до 10-12 до 12. Також зауважте, що початковий конус має діапазон 16x при виконанні початкової концепції.

Відповіді:


13

Чесно кажучи, як пише у своєму книзі Чорний лебідь Нассім Ніколас Талеб: "ми просто не можемо передбачити". В основному через невідомих-невідомих. Як правило, найкраще повідомити цей факт, той факт, що ви не можете передбачити, а не повідомляти оцінку.

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

Кажучи таке, той, хто просить вас оцінити щось, розуміє, що все не так просто.


3
+1: це єдина правильна відповідь. Навчити менеджера приймати невідомі - це набагато простіше, ніж оцінювати їх. - Також перегляньте роботу Стіва МакКоннолла на сайті construx.com.
mattnz

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

2
@ThomasOwens Ви маєте рацію, не варто просто ходити за цим. Але мій сміливий вислів мав на меті тлумачити: не обманюйте себе чи не обманюйте свого начальника, але будьте відкриті в тому, що оцінка буде важкою! Тому що чесно, не кожен менеджер, який запитує оцінки, усвідомлює, наскільки важко / неможливо його зробити.
Мартен Ситема

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

3

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

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

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

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

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


3

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

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


1

Залежить, я використовував FPA ( Function Point Analysis ) більшу частину часу, але ми входили в цю "веб-розробку enterprizey", я маю на увазі, ви знаєте, веб-компанії Forbes 500.

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

У легкій версії складне завдання - це вже написаний компонент, просто важко і невідомо взаємодіяти з ним.

Важка версія - це коли потрібно писати, а потім оцінювати на основі пілотних програм, COCOMO, і все.

Однак дві важливі речі:

  1. Кожна система оцінки повинна мати час калібрування для вашої організації. Ви ніколи не розвиваєтеся наодинці, принаймні, клієнт чекає вашого коду (інакше ви не будете настільки відчайдушні з цього приводу, написавши код заради себе). Питання не в тому, «як швидко його можна розвинути?», А «як швидко його можна розвинути з усіма вами?».

  2. Одного разу у мене був менеджер, який читав той роман Чорного лебедя і маніакував його. Він говорив нам, що неможливо оцінити, і я невпинно робив свої звичайні точні до + -10% оцінки ...


-2

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

Вибачте, що це зовсім не допомагає.


-4

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

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


4
Чому 4? Чому б не 5? 10? 33,3? ... Чи стоїть наука за вашою відповіддю чи просто вибираєте випадкове число? Якщо врахувати, що у Вашій відповіді це може зробити його більш корисним.
Брайан Оуклі

у відповідній записці, не соромтеся великої кількості. Колись мій колега підрахував переробку модуля за 935 (дев'ять-три-п’ять) днів. Бос сказав, що нас не так багато, і замовив 60 днів. Колега зробив усе, що можна було в 60-х. Результат був досить клопітким, але його ніколи не звинувачували в цьому. Потрібно визнати, що 60-денна версія, як би не було клопітно, дозволила нам отримати досить важливого клієнта - тобто, поштовх боса - дуже гарний бізнес-сенс. BTW врешті-решт нам вдалося налагодити цей модуль у формі, але це сталося через кілька років, і зусилля, які були докладені, були більше в бальному парку з оцінкою 935
гнат
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.