Всім привіт. Мене звуть Володимир Завертайло, я - керівник студії інтернет-рішень «Сібірікс».
Чи часто вам доводиться відповідати на питання «Скільки коштує сайт?»? Як багато навідних запитань ви задаєте, щоб прийти до якоїсь сумі і озвучити її? Чи потрібно її озвучувати, якщо не ясні деталі ТЗ? Що робити з потоком заявок - оцінювати кожне ТЗ індивідуально або використовувати шаблонні оцінки? Чи задоволені розробники закладеними термінами, а клієнти - сумою бюджету?
Практика підказує, що не все так просто при оцінці. Щоб зробити чітку і адекватну оцінку будь-якого проекту, потрібно досить багато часу кваліфікованого фахівця, який не факт, що буде оплачено. Наведу приклад: близько року тому у нас пішло близько чотирьох робочих годин в день у двох кваліфікованих розробників, щоб виконати оцінки по всім приходять заявками. Це наганяло тугу, і ми вирішили виправити ситуацію.
Сьогодні, при збільшеному обсязі заявок, трудовитрати на оцінки становлять близько 20 хвилин в день, причому більшу частину з них роблять менеджери проектів (не технічні фахівці), при цьому точність значно зросла. І сьогодні я б хотів розповісти про простих і ефективних методах, які ми застосовуємо щодня:
1. Найпростіший і вірний спосіб зробити оцінку - це не робити її. Звучить дивно? - Але працює. Потрібно безпосередньо з'ясувати бюджет проекту у клієнта.
Чому це може спрацювати?
По-перше, у клієнта все одно є бюджет, який він планує витратити. Занадто сильно він не стане за нього заходити при будь-якому розкладі.
По-друге, при цьому може виявитися, що бюджет у клієнта значно нижче того, що ви зазвичай берете за такого роду проекти. Тут нам на допомогу приходить всім відомий принцип Парето - 80/20. Суть в тому, що основні корисні, потрібні і приносять прибуток функції проекту складають, як правило, близько 20% (правда, є лідер по незатребуваним функцій - програма MS Excel, де постійно використовується близько 4%). Знаючи цей принцип, ви повинні обговорити бізнес клієнта, допомогти йому визначити, які функції для нього будуть ключовим і принесуть максимальну віддачу, і при цьому вам, швидше за все, вдасться вписатися в бюджет.
Чому це може не спрацювати? З різних причин. Досить поширена - клієнт просто моніторить ринок і шукає найнижчу ціну (у вас коли-небудь просили зробити знижку від ціни, яку ви назвали як "ВІД", і причому зі стелі?).
2. Другий спосіб підійде для швидкої, але неточною оцінки товстих фоліантів ТЗ або якийсь рутинної роботи. Як метрики буде використовуватися. ScrollBar. В чому сенс? - Припустимо, вам прислали матеріали для набивання каталогу товарів, кілька сотень листів в Word і пачку невідсортованих фотографій. З ходу зрозуміти, скільки займе часу вбити цей каталог, досить складно. Беремо, починаємо вносити товари, і заміряємо час. Вбили кілька штук - по тому, як змістився scroll-бар в документі, приблизно бачимо наш прогрес (у відсотках). Далі - справа техніки, перемножити два числа.
У випадках з оцінками ТЗ - ви берете і вибірково оцінюєте пару сторінок, примножуєте на кількість сторінок, коефіцієнт вашої невдачливості і коефіцієнт корпоративної жадібності. Все, оцінка готова. Прекрасно працює на великих, детальних, однорідних ТЗ, які потрібно оцінити швидко. Іноді дає серйозні збої, якщо десь на передостанній сторінці через кому перераховані десятки модулів без деталізації. Упс.
4. Дуже хороший спосіб зробити оцінку - "Planning Poker". Команда, яка буде працювати безпосередньо над проектом, збирається разом і починає обговорювати кожну фичу проекту. Кожному члену команди видається набір з 13 карт різного номіналу. Після того як ведучий пояснив, як повинна працювати конкретна фіча, всі члени команди повинні покласти карти зі своїми оцінками сорочкою вгору. Після цього відбувається розкриття карт.
Якщо оцінки співпали - значить, оцінка ясна, і вся команда з нею погодилася. Якщо немає - це означає, що або завдання не зрозуміла (наприклад, людина, яка викинув не те число, проспав постановку задачі), або один з членів команди знає якісь особливості обговорюваної задачі (наприклад, підводні камені або якийсь швидший спосіб вирішення). У цьому випадку той, чия оцінка не збіглася з командної, повинен пояснити, чому він витягнув саме таку карту, і які він бачить нюанси реалізації. Після цього кін переграється повторно.
Цифри на картах. в залежності від обставин, можуть означати години, дні або «Story point». При оцінці в «Story point» ми вибираємо найменшу фичу в проекті і вважаємо її еталоном. Всі інші фічі оцінюються щодо обраної.
У колоді крім цифр є спеціальні карти - "перерва на каву / пиво", ". "(Використовується новими розробниками, які не можуть дати оцінку)," 0 "(якщо фіча готова або робиться за хвилину).
Процес досить тривалий, займає годину-дві або більше, в залежності від досвіду команди і обсягу проекту. Ідеально підходить для великих проектів, в яких команда працює по scrum і набирає собі завдань на найближчі два-чотири тижні (спринт). Додатковий плюс - проект і деталі реалізації стають зрозумілі всім, а за зроблені оцінки з'являється почуття відповідальності.
Я рекомендую завжди робити оцінки термінів по всіх проектах, неважливо, за внутрішніми проектами студії або проектам для замовника - якими б маленькими вони не здавалися. (Навіщо? Про це можна почитати і подивитися в нашому блозі або погуглити за запитом "Закон Паркінсона").