Створення системи управління проектами на Yandex Tolstoy Camp

    У перервах між розробкою мобільних рішень для великих замовників, в голову постійно приходять ідеї нових сервісів. Щоб не відкладати їх реалізацію в довгий ящик, ми вирішили дати самим собі під зад і пройшли відбір у Yandex Tolstoy Startup Camp 2014.
 
Ми працюємо над створенням нової системи управління проектами. Головна мета — розробити інструмент, який допоможе невеликим студіям точніше оцінювати проекти, знижувати ризики виходу проектів за терміни і бюджет, повніше бачити картину того, що відбувається.
 
 
 
Якщо ви чули про підхід Lean Startup, ви повинні знати і про Customer Development — підході, який змушує стартаперів не сидіти і мовчки пиляти геніальний продукт півроку, а виходити до своїх потенційних клієнтів відразу, шукати їх реальні проблеми і вирішувати їх. Так от, оскільки користувачі Хабра — наша потенційна цільова аудиторія, ми будемо перевіряти наші гіпотези про проблеми на вас =). Ми будемо регулярно робити пости про те, як розвиваємося, які гіпотези підтвердилися, а які були спростовані, як змінилося бачення нашого продукту в ході кастдева і скільки грошей ми заощадили в порівнянні із звичайним підходом (пиши код, б ❚ ❚ ❚ ❚ ❚!), ну і розповідати про Lean Startup і Customer Development.
 
Отже, якщо ви менеджер проектів або CTO, хочете взяти участь в інтерв'ю і висловити свою думку про те, як повинна виглядати система управління проектами вашої мрії, або просто хочете побачити, як працює customer development в стартапі зсередини — ласкаво просимо під кат.
 
 
Багато хто, почувши словосполучення «нова система управління проектами», напевно, подумають — чим же вона відрізняється від існуючих інструментів начебто JIRA, Redmine, Asana, Мегаплан та багатьох інших. З нашої точки зору, всі ці системи гарні, але навряд чи можуть називатися "системами управління проектами", оскільки вони покривають лише деякі процеси з тих, що відбуваються в проекті (приклади таких процесів — оцінка задач, розробка ієрархічної структури робіт, контроль і управління вартістю проекту; є й інші. Таск-трекери, як випливає з їх назви, покривають управління завданнями частково кілька інших процесів — звітність, контроль якості).
 
Ми хочемо створити систему, яка буде покривати набагато більше процесів. Навіщо? Сподіваюся, що відповідь на це питання стане зрозумілий і вам, і нам =) з наших подальших публікацій.
 
 

Проблеми…

Розглянемо невелику студію, яка займається розробкою мобільних або веб додатків на замовлення. Зазвичай, кожен проект такої студії ділиться на кілька кроків:
 
     
  1. збір вимог із замовника, первісна оцінка та продаж;
  2.  
  3. після підписання контракту — фаза аналізу і розробки дизайну. До завершення цієї фази замовник отримує більш-менш точний work breakdown із зазначенням компонентів разрабативамой програми, підтримуваних use case'ов, з проставленою навпроти кожного елемента ціною. Формат цього документа зазвичай файл Word або Excel:
          
                   
    Компонент / функціональність Дизайн Розробка Тестування
    Логін 50 150 75
    Стартова сторінка 100 500 200
    Менеджер проекту вибиває необхідні ресурси собі на проект, розуміє взаємозв'язок між завданнями, тому в додаток до документа з оцінками, замовнику може бути наданий план проекту у вигляді діаграми Ганта, складений, наприклад, в Microsoft Project.
  4.  
  5. Після остаточних узгоджень починається, власне, робота над проектом. Менеджер проекту заводить завдання в таск-трекер (наприклад, JIRA); починається перший спринт, якщо команда працює за scrum; йдуть щасливі трудові будні.
  6.  
 

… і небезпеки

З нашої точки зору, подібні проекти підстерігають наступні небезпеки:
 
     
  • На етапі оцінки не проводиться оцінка ризиків. Точніше, кожен учасник процесу оцінки примножує цифру, яка спочатку прийшла в голову, на 2 (а досвідчений оцінювач — на 4 =)), але що це за ризики і чи потрібно їх збільшити / зменшити для даного проекту — зазвичай не знає ніхто.
  •  
  • Такий підхід ускладнює переговори з замовником, оскільки сейлз складно зрозуміти, на скільки він може знизити початкову ціну до того, як проект перестане бути прибутковим. У результаті компанія пропонує ціну вище, ніж конкуренти, і втрачає потенційного клієнта.
  •  
  • Артефакти, створені в результаті оцінки, рідко потрапляють в таск-трекер в тому ж вигляді, в якому вони були представлені замовнику. Це ускладнює підрахунок actuals по кожній розроблюваної фиче (екрану, use case'у) окремо і не дає зрозуміти, чи можемо ми дозволити собі витратити на неї більше часу або вже немає.
  •  
  • PM'у доводиться регулярно і вручну синхронізувати інформацію в баг-трекері, плані проекту, звітах, які він посилає керівництву компанії і замовникам. При цьому нерідко трапляється, що пункти в Excel, за якими він звітує перед замовником, не мають нічого спільного зі списком завдань у трекері (див. пункт вище), і підготовка кожного такого звіту вимагає чимало зусиль для розуміння, якою ж відсоток готовності тієї чи іншої частини функціоналу.
  •  
  • У PM'а немає розуміння того, скільки дійсно ризиків було закладено при оцінці і після досягнення якої цифри fact проект працює у збиток (ну або просто знижує маржинальність проекту)
  •  
Чи стикаєтеся ви з подібними проблемами? Як ви їх вирішуєте? Будемо раді вашому фідбек з даної теми в коментарях до посту. Також, просимо витратити кілька хвилин і заповнити опитування .
 
Особливо вдячні ми будемо тим, хто погодиться витратити 30-40 хвилин свого часу на скайп-інтерв'ю. Для цього потрібно просто зареєструватися на сайті www.snapyourproject.com і поставити галочку «зв'яжіться зі мною» — і ми прийдемо за вами =). Якщо ви живете і працюєте в Москві, ми будемо раді зустрітися з вами особисто, щоб дізнатися вашу думку.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.