KoderLine
KoderLine
Обслуговування i продаж
програмного забезпечення

Статті експертів

Корисна інформація

Найбільш типові помилки при оцінці робіт в проектах Підприємство 8

0
31
13.05.2021 Іван Аюпов
Зміст

1. Помилки програмістів і віддалених розробників
2. Помилки аналітиків - консультантів
3. Помилки при оцінці послідовності проведення робіт


Для кого ця стаття? Якщо ви керівник проектів (КП) з досвідом «від трьох проектів», то можете не читати: швидше за все, нічого нового ви не дізнаєтесь. А якщо ви хочете стати КП в проектах Підприємство 8 або ви професіонал (розробник, аналітик, консультант), до якого часто звертаються за оцінкою, то вам буде корисно дізнатися про типові помилки при оцінці.

Якщо вам необхідно реалізувати завдання, яке не має сенсу робити за класичною проектною технологією, але замовник вимагає фіксованої оцінки, і завдання на 2-5 людино-місяців, - то вам буде корисно зрозуміти методи оцінки робіт.

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

Типові помилки розподілені за класами.


 


1 Помилки програмістів і віддалених розробників

1.1.        Недооцінка часу на тестування та виправлення.

Подумайте, ви справді вмієте програмувати відразу без помилок? Якщо немає, сміливо закладайте час на тестування. Скільки? Залежить від завдання - ви професіонал, вам видніше.

1.2.        Недооцінка часу на уточнення формулювань завдання проекту.

Вам відразу зрозуміло ТЗ? Точно відразу? Ви точно знаєте, що замовник завдання вам сказав? Скоріше за все ні. І це правильно - повністю формалізувати ТЗ до рівня всіх алгоритмів ніхто не буде (а особливо замовник). А це означає, що вам доведеться уточнювати задачі. І це нормально. Виділіть на це час, якщо завдання велике.

1.3.        Недооцінка часу на підготовку “дороботи”.

Де відбуватиметься розробка? У вас на комп'ютері? На сервері замовника? На сервері компанії? А база вже розгорнута? А є доступ? А отриманий чи cf, якщо «конфігурація замовника трохи змінена»? Ці питання треба задати і зрозуміти, чи потрібен час на підготовку. Якщо потрібен, і готувати будете Ви, включайте час в оцінку.

1.4.        Недооцінка здачі-приймання.

Подумайте, кому і яким чином ви будете здавати роботу? Що для цього потрібно? Скільки це займе часу? Ви здаєте роботу не одній людині, а кільком (таке буває)?

1.5.        Недооцінка оточення.

Замовник використовує сховище конфігурації, розробка ведеться в розширенні, «ось вам простий і зрозумілий регламент роботи і документування коду всього на 25 сторінках»? Якщо ви з цим працювали, то розумієте: на скільки помножити, якщо робота зі сховищем; на скільки, якщо з розширенням; скільки відсотків на сторінку регламенту закладати. Якщо не працювали - сміливо множте на 1.5 за кожен вид невизначеності. Швидше за все, все одно не вгадаєте, але це буде не так образливо.

1.6.        Чи не вказали кордону.

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

Тут 100% діючого рецепта немає - під час постановки завдання можуть не сказати що завгодно. Якщо умови невідомі, пишіть свої припущення і їх вважайте «кордоном». Якщо ви мали на увазі, що ви тільки кодуєте, тільки у себе, а в якості здачі-приймання відправляєте cf поштою - напишіть. Замовник або погодиться, або задумається і скаже: «Ні, я хочу, щоб ви мені тестовий стенд розгорнули і показали, як це працює». Тоді ви вже вступаєте в конструктивний діалог: «А тоді це буде коштувати ще ...». У будь-якому випадку, ви не будете працювати безкоштовно: якщо з'ясується, що замовник не готовий за щось платити, ви самі приймете рішення, готові ви щось зробити за безкоштовно, або нехай пошукає кого іншого.

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


 

2 Помилки аналітиків - консультантів

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

1.1.        Правильно розписана послідовність робіт.

Ви ж розумієте, як будете вирішувати поставлену задачу? В якій послідовності? Що буде результатом? Якщо розумієте, то напишіть цю послідовність. Найкраще в MS Project. Так вам стане зрозуміло, коли ви насправді зробите завдання.

1.2.         Чи закладено резерв на виправлення помилок.

Чи може ваш результат містити помилки? Скажімо, в інструкції? Якщо може, то закладайте час на виправлення помилок.

1.3.        Чи закладено резерв під здавання-прийняття виконаних робіт.

Як ви будете здавати роботу? Кому? Скільки це насправді займе часу? Чи треба буде кудись їхати? Чи треба там когось чекати? Чи зможете ви зробити щось ще, якщо поїдете здавати завдання до замовника на Горобинову вулицю до 15? Якщо немає, то чому б не включити години вимушеного простою в години роботи на замовника, через якого ця затримка викликана?

1.4.        Чи враховуєте транзакційні витрати.

Що це таке? Дуже просто. Наприклад, у вас міні-проект і ви домовилися про серію інтерв'ю для уточнення завдання. І ось перше інтерв'ю у вас о 10:00, а друге о 15:00. Чим ви будете займатися між ними?

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

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

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

1.5.        Чи фіксуєте результат, або фіксуєте нечітко.

Це поєднується з пунктів 2.3, 2.4. Подумайте, що буде результатом вашої роботи. Якщо складно зрозуміти, зверніться до більш досвідчених товаришів, які пояснять, наприклад, що результат інтерв'ю - це протокол, що інструкція по роботі - теж результат. І повертаючись до п.2.3: відразу подумайте, як ви будете це здавати, і що є критерієм коректно отриманого результату. Це позбавить вас від прекрасних формулювань типу «коректна працює система, що формує правильні проводки» (сам такі робив). Якщо опис результату допускає двояке трактування - будьте впевнені, ви з Замовником зрозумієте по-різному. Якщо не допускає, то теж зрозумієте по-різному, але вам принаймні буде що сказати. 


 

3 Помилки при оцінці послідовності проведення робіт

Тут піде мова про оцінку міні-проектів, де буде працювати не тільки аналітик, але і розробник (або два). Як тімліда в таких конструкціях зазвичай виступає аналітик, який і спілкується з замовником, ставить ТЗ, приймає роботи у розробників і здає результат Замовнику.

1.1.        Неправильно вказана послідовність проведення робіт.

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

Пам'ятайте, що розробники помиляються з оцінкою (див розділ 1).

Пам'ятайте, що не можна писати інструкцію по неопрацьованому функціоналу (наприклад).

1.2.        Не враховано транзакційні витрати.

Як буде відбуватися передача завдання від вас програмісту? А від програміста до вас? Що він буде робити, поки ви перевіряєте результат?

1.3.        Перевантаження ресурсів.

У вас проект на 9 людино-місяців, а треба зробити за один. Здавалося б, беремо 9 програмістів, і вони все зроблять за місяць. Але ні! Якщо один аналітик і дев'ять програмістів, то завдання буде робитися швидше за все близько року. Так-так, та сама, на 9 людино-місяців.

Чи не ваш випадок? Так якщо у вас шість програмістів на 50% завантаженні, то це гірше, ніж 3 на 100%.

Чому? Тому що як би не було декомпозироване завдання, як би ви не написали ТЗ, вам будуть задавати питання при розробці (ті самі, з п.1.2) Одній людині ви поясните один раз. Шести - шість. І питань буде в 6 разів більше.

1.4.        Помилки оточення.

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

Список не є вичерпним, але основне я вказав. Тепер абзац для замовників.

Отже, шановні замовники, якщо ви - одержувач оцінки, то треба всі ці питання (з пунктів 1-2) задавати вашому виконавцю. Інакше може вийти, що ваш виконавець отримає значно менше, ніж витратить часу. А вам-то що? Дуже просто: він пару раз з вами попрацює, а потім вирішить, що йому так не треба. Або скаже, що більше не хоче так працювати, або просто зникне (добре якщо без передоплати). Тому якщо ви націлені на довгу співпрацю - задавайте ці питання. Цінуйте фахівців, які проводять роботи в програмі Підприємство 8, їх і так мало!

Іван Аюпов ,
Спеціаліст компанії ТОВ «Кодерлайн»



Добавить комментарий
Message Text*
Spam bot protection (CAPTCHA)
Load image