Оцінки. Процес, який розробники так ненавидять, але це так потрібно для успішного старту проекту.
Ви коли-небудь замислювалися над причиною, чому розробники ненавидять настільки таку просту річ, як груба оцінка перед початком проекту? І чому трапляється так, що різні компанії надають різні оцінки одних і тих самих завдань / проектів? Я спробую відповісти на ці запитання.
Оцінки. чому розробники так погано ставляться до них?
Як одного разу сказав Джон Ромеро, «Ви можете не думати, що програмісти – це художники, але програмування – надзвичайно творча професія. Це творчість, заснована на логіці “.
І це не лише слова. Як і кожна творча професія, програмування має свої добрі та погані дні, злети і падіння. Один день можна написати 100 і менше рядків коду, а інший раз – 1000 рядків. Виправте кілька старих питань або зробіть десяток нових). Додавши той факт, що над проектом зазвичай працює кілька людей, і, на закінчення, ми отримуємо вражаючу комбінацію “людських факторів”, яка сильно впливає на проект в хорошій чи поганій формі. Існує багато способів покращити оцінки, але всі вони схожі на «самурайський шлях» – шлях до досконалості, який ніколи не закінчується. 100% точність неможлива. u
Звичайно, якщо вам потрібно створити 10-сторінковий веб-сайт, це навряд чи можна назвати програмуванням. Це звичайний процес, і найгіршим сценарієм тут може бути деяка несумісність CSS. Це та частина, яку можна було б виміряти з точністю.
У цьому різниця: коли процес автоматизований, це вже не питання творчості. Якби дія була здійснена багато разів у минулому, кінцевий результат можна було б точно спланувати та виміряти. Ви знаєте, наскільки швидко вони працюють у Макдональдсі. Це відома хвилинна послуга, заснована на багатьох експериментах та автоматизації .. Ніякої творчості, лише механіка.
Чим кращий розробник – тим швидший процес розробки.
Так я думав на початку своєї кар’єри. Саме так думає більшість клієнтів. І це велика помилка, особливо підступна, оскільки вона має абсолютно логічне підґрунтя: майже все, що ми робимо у своєму житті, маючи більше досвіду, ми робимо швидше. Після деяких тренувань ми можемо зробити багато речей швидше: читати, писати, бігати, говорити, їсти, одягатися … або роздягатися. І в цьому магія автоматизації.
Коли я отримав свій перший серйозний проект у 2014 році, я був так схвильований, що вирішив найняти додаткового розробника з хорошим досвідом для цього проекту. Мої очікування були досить простими. Ми планували, що це зробить за три місяці один програміст, і після того, як ми додамо старшого розробника, ми закінчимо проект набагато швидше, ніж очікувалось, і порадуємо нашого клієнта. Ми також покращили б свою команду за допомогою досвідченого товариша по команді. АЛЕ …
Ми ніколи раніше не використовували деякі функції, які виявились важливими, якщо ви хочете зробити хороший продукт: адекватна взаємодія зі сховищами, планування архітектури, модульні тести, тестування якості … Коротше кажучи, загалом ми витратили На 50% більше часу, ніж очікувалося. Клієнт розсердився на затримку, розробники були виснажені моїми постійними наполяганнями, і проект, який повинен був дати поштовх нашій команді, став збитковим (це був проект із фіксованою ціною).
Це була втрата грошей, але потужний удар для мого досвіду створення якісного продукту.
Тож чим кращий розробник, тим кращий продукт. Це НЕ буде швидше. Це сумно, але правда ..
Скільки часу потрібно, щоб намалювати коня?
Кілька тижнів тому у мене була кумедна ситуація, коли ми оцінювали розробку програм для Android, і загалом ми розрахували близько 400 годин. Наш клієнт був щиро здивований тим, що всі оцінки, які він отримав від різних компаній, були різними, а найнижча оцінка становила близько 100 годин. “Це величезна різниця, – сказав він, – чому я повинен платити більше і чекати більше, якщо я можу придбати той самий товар дешевше і швидше?”
Боб, сподіваюся, ти не проти, я скористаюся тим самим прикладом, який я сказав тобі натомість)
Ось технічне завдання для малювання коней: «Намалюй реалістичного коня олівцем. Одну ногу потрібно підняти. “
Виконавець1: 15 хвилин
Виконавець2: 45 хвилин
Виконавець3: 1 година
Кінцевий результат ..різний .. Ці приклади показують пряме співвідношення витраченого часу та якості.
Професіонал ніколи не буде недооцінювати не тому, що він хоче отримати більший прибуток, а тому, що якщо він витрачає менше часу на отримання результату, якість постраждає, а кінцевий результат буде не таким хорошим, як очікує клієнт.
Будь-яке із цих зразків зображень з часом можна вдосконалити. Чи можна було б вдосконалити щось, що зробив недосвідчений художник? Наприклад, уявімо, що був ще один конкурент, який був готовий надати результат за найнижчу ціну, навіть якщо на його розробку знадобилося близько 1 години?
Технічно доручення виконується у всіх випадках. Кожен зробив свою справу. Але це абсолютно різні продукти. У програмуванні трапляються ті самі речі, що ми спостерігаємо на малюнку: якщо основа зображення неправильна, незалежно від того, скільки часу ми на це витрачаємо. Остаточна картина буде зіпсована, і вона ніколи не буде виглядати так, як планувалося.
Те саме відбувається (багато!), Коли вони намагаються побудувати свій проект із мінімально можливим часом та (або) ціною. Індійські розробники завжди раді допомогти. І є ймовірність того, що ви отримаєте якийсь робочий продукт. І цей продукт був би схожий на дешеву іграшку від AliExpress – приємна ідея, але повна реалізація робить їх непотрібними … Найгірше – у більшості випадків ви не можете нічого зробити, щоб виправити це, жодне полірування не допоможе, какашка все одно какашка, переписувати все з нуля – єдине рішення в більшості сценаріїв з недосвідченими індійськими розробниками (я вважаю, що мають бути справді кваліфіковані хлопці, хоча я ніколи таких не зустрічав).
На закінчення, якщо ви хочете бути впевненими в оцінках, які ви отримуєте, краще запитати подробиці про те, як було зроблено цю оцінку, перевірити декомпозицію. І краще вибирати між середніми результатами. Про все видатне слід турбуватися.
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/estimations-expectations-how-long-does-take-draw-horse-sergey-dziupin/.
Sergey Dziupin люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 