На днях сталась зі мною одна нездорова оказія, яку ще можна стерпіти на початку кар’єри, але не на десятому році роботи… Завалив ваш покірний слуга терміни по проекту, завалив злосно.
Ну, клієнта перепросили, повернули гроші, перепросили ще раз. Але мазафака — карму тим сильно не поправиш, потрібно хоча б висновки зробити.
А висновки такі, малята:
- поганих чи добрих людей в рамках співпраці не буває в принципі. Бувають суб’єкти, наділені суперопціями: кваліфікації, оперативності, прогнозованості;
- не буває проблем — бувають ситуації. Дана повна жопа зі створенням проекту складалась з низки заходів, які доповнювали повноту.
Якби я тепер писав конституцію процесів, то ще раз би виділив пункт: розбивати загальну картинку на конкретні кроки. При чому зробив би собі гарне татуювання з цим тезисом.
Конкретні кроки прописуються в біблії проекту і результат кожного кроку демонструється замовнику — приблизно так само як домашні коти приносять замовнику мишей під поріг.
Звіти це штука непроста. Попри те, що клієнт має відчувати поступ в розробці, є сенс притримати зайвий апетит — це коли в процесі задача видозмінюється в сторону ускладнення.
Для цього непогано юзати такий параметр як in one shot — це приблизний шмат роботи, який може бути зроблений за вечір-два. Часто буває так, що розробник за пару підходів робить тижневий об’єм роботи, 80%, а потім місяць дотягує кілька тасків загальним об’ємом в 15 годин…
in one shot — показує замовнику, скільки його завдання ще буде в пріорітеті, адже незалежно від взаємин між двома людьми, продуктивність над проектом часто знижується, коли завдання розтягується.
Відтак, врахування такого моменту в співпраці часто дозволить передбачити чимало недобрих моментів ще на початку роботи, роблячи з етапів автономні області, подальша робота та обслуговування яких може бути передана іншому девелоперу з нерозтраченим надхненням.