Waterban, PlanTrack, GtkSharp та інші смішні словосполучення - пара думок про те, чому варто зробити рішення щодо УП під себе

Waterban, PlanTrack, GtkSharp та інші смішні словосполучення - пара думок про те, чому варто зробити рішення щодо УП під себе

Всім добрий день!

Цей короткопост буде ходити біля питань проектного управління, здобувши це прототипом реалізації ідеї суміщення канбана і водоспаду.

Преамбула

Неодноразово стикався з картиною: від менеджера вимагають сказати кінцевий термін і дають в руки трекер завдань. Рішення буває таке - план проекту в MS Project/TeamWork або в якомусь звичному для Waterfall інструменті, а для трекінгу кастомізована Jira/Trello або щось ще. Дивився я на муки менеджерів з актуалізацією туди-сюди, і народилася ідея одружити Waterfall і Kanban: методично і практично (в рамках наколінно-доморощеної реалізації на Gtk #).

Амбула ніби

Методично

Канбан - це в першу чергу аналіз зміни статусу завдань. Звичний waterfall - це аналіз послідовності завдань. У цьому плані на перший погляд перетину ніякого немає - заплановані завдання можуть змінювати статус (і навіть в MS Project або хоч де). Однак прогноз канбана будується на часі проходження завдання до кінцевого статусу, і статуси змінюють виконавці самостійно, чим створюють факт, в той час як водоспад дає нам планові терміни. Щоб об'єднати це в одне, досить примітивно дати можливість виконавцям ганяти по канбан-доріжках завдання водоспаду в будь-яку сторону. Звичне завдання менеджера після створення водоспадного плану зведеться до аналізу відхилень від нього - в той час як звична справа розробників та інших виконавців проекту зведеться до зміни статусів завдань.

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

Таким чином, канбан і водоспад цілком сумісні один з одним, і завдання відстеження можна спростити за допомогою сильних зв'язків.

Практично

Для практичної реалізації був обраний C # і Gtk # (оскільки я linux-користувач, а хотілося кроссплатформенності). Реалізацію (знову ж не думаючи довго) назвав я PlanTrack, і поточний її стан - прототип.

Лайка з приводу поточної реалізації

Як з'ясувалося, Gtk # не настільки кроссплатформенний, наскільки хотілося (під Windows потрібно затягнути купку бібліотек). По-друге, вибір бази Sqlite теж був досить наївним - потрібні різні збірки під різні платформи. Ті, хто захоче зібрати проект під linux, повинні будуть змінити в коді три рядки (в DBHelper.cs: System.Data.SQLite -- > Mono.Data.Sqlite, і в тому ж файлі в двох місцях SQLiteConnection -- > SqliteConnection).

Більше того, на солодке. Мої вибачення за код похапцем, часу у мене як завжди в обріз (працюю навіть на святах), але навіть справа не в цьому. Виглядає все інтерфейсне господарство під Linux і під Windows боляче вже по-різному.

Скріншоти

Посилання на windows-збирання (прочитайте readme!).

Постамбула

Про що піст - може і не про ідею, і точно не про реалізацію (мої вправи щодо Gtk # навряд чи кому згодяться).

Пост швидше про те, що створення своїх інструментів може себе виправдати. Я не раз і не два робив (в якості PM'a) різні рішення з управління проектами, містечкові - в тих місцях де працював. Навіть на 1С припадало. І знаєте що? Заточений під себе інструмент дозволяє забивати цвяхи відразу прямо, а не натягувати свою роботу під чиїсь роздуми про те, як треба б.

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

У цьому і вододіл. Не можна, мабуть, вірити в те, що ми візьмемо RUP/XP/Scrum/< Список довгий > і тепер заживемо. Ні, не заживемо, а поіміємо проблем. Ні, не можна взяти MS Project і Jira і сказати - ось тепер ми в них трекаємо і плануємо, тоді все буде добре. Ні, добре не буде.

Добре буде тоді, коли хтось візьме, наприклад, Excel, і на макросах VBA зробить те, що підходить вашому бізнесу. Була справа я працював в одній великій компанії (що обертається на Лондонській біржі) - і там ніхто не замовляв халепу SAP. Оцінка і відстеження проектів були зроблені під себе, під свої проекти, під свої методи. І в Excel. Працював я і в компаніях в 500 разів (без перебільшення) менше - і там створення своїх проектних рішень себе виправдовувало. Чому?

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

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

Хороших свят і вдалих проектів!

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

Image