1. ***

Постараємося ще раз застерегти від повторення загальновідомих помилок. Автор сам був активним учасником проектів, про які розповідає; практично всі вони виконувалися в Росії, фінансувалися вітчизняними замовниками, керувалися вітчизняними менеджерами і реалізовувалися вітчизняними розробниками.

«До сих пір залишилися без відповіді питання, чому цілком розумні організації роблять подібні проекти, і чому розумні менеджери і технічні фахівці погоджуються брати участь в таких проектах» [ 1 ]

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

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

Проблема щирих відносин з замовником стоїть дуже гостро. На жаль, її посилює специфіка вітчизняної бізнес-етики. Ключова проблема закладена в договірній основі проекту - відсутність добре відпрацьованої специфікації і стандартних механізмів, що заважають взаємодії між замовником і виконавцем. Нарешті, часто є неформальні причини укладення контракту або його додаткові умови; привабливі для виконавця в момент отримання авансових платежів ці обставини можуть вкрай негативно позначитися в майбутньому. Однак практика показує: незрівнянно краще повідомляти про всі неприємності самому і відразу, ніж чекати, коли замовник зрозуміє, що розробка програми, за яку він платить, просувається не так успішно, як його запевняють менеджери компанії-виконавця, розмахуючи красивими звітами, виконаними в повному відповідно до методології, про яку нормальній людині краще нічого не знати.

«Наївний оптимізм юності: Ми зможемо зробити це за вихідні!»

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

Ризикнемо припустити, що запал, працездатність, здатність уникати шаблонних рішень і пов'язаних з ними проблем і помилок, а також легкість в спілкуванні і віра в перемогу в стані якщо не гарантувати, то хоча б наблизити команди розробників до бажаних результатів. Але, як справедливо запитує Фредерік Брукс, «чому ж досі всі професійні бригади програмістів не замінено одержимими дуетами з гаражів?» [ 2 ].

Необхідно фіксувати версії

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

А ось реальний випадок. На платформі Eclipse, підтримуваної компанією IBM, розроблялася утиліта для перевірки файлової системи. В останній момент було запропоновано додати одну перевірку і з'являється в разі її невдалого завершення діалогове вікно. Всього два рядки на Java. Однак через кілька днів після здачі проекту з'ясувалося, що програма стала поводитися трохи дивно - горезвісне діалогове вікно з'являлося випадковим чином. Після довгого тестування з'ясувалося, що помилка була наведеної, обумовленої витоками пам'яті. Але керівник розробки вже нічого не міг зробити: він був зобов'язаний ліквідувати помилку, в результаті чого витрати на розробку і супровід істотно перевищили бюджет.

Втім, значимість «зафіксованої версії» ширше. У всіх методологиях, що мають на увазі Інкрементальний розробку, фіксація версії є ключовим моментом для вибору тактики поведінки на наступній ітерації, прийняття рішення про необхідність внести зміни в використовувану методику [5]. Це також єдиний спосіб забезпечити можливість швидкого «відкату» в разі незадовільних результатів наступного етапу. Але є і психологічний аспект; необхідні чітко зафіксовані віхи, дні, коли команда може зітхнути і сказати: «Ми це вже зробили!»

«Срібної кулі немає»

Ця тема [2], здавалося б, досліджена вздовж і поперек, як і раніше залишається джерелом величезної кількості помилок. Знову і знову керівники команд приступають до проектів, вибравши чергову диво-технологію і будучи щиро впевненими, що саме вона стане запорукою успіху. UML для проектувальника, ASD для менеджера проекту, компонентна модель для архітектора, Java для програміста ... Число провалених, які перевищили всі заплановані ресурси, закритих проектів менше не стає.

Незважаючи на багато разів сформульоване правило - «жодна технологія не дозволить підвищити продуктивність праці в програмуванні на порядок», з метою зниження вартості продукту замовник наполіг на тому, щоб в якості платформи для реалізації нового сервера додатків була обрана ОС Linux з ядром 2.4. Наші пропозиції провести дослідження і з'ясувати, чи годиться платформа для вирішення поставленого завдання, замовник відкинув, посилаючись на брак часу, консультації з експертами та публікації в численних виданнях, які свідчили про придатність платформи. В результаті, розробникам довелося зіткнутися з величезним числом складнощів, пов'язаних, в першу чергу, з невідповідністю описів тих чи інших програмних інтерфейсів і їх реалізацією. Скажімо, функції бібліотеки pthreads працювали зовсім не так, як вимагає POSIX. Проект врятував лише попередньо розроблений шар, абстрагуватися код від конкретних реалізацій необхідних йому сервісів (многопоточность, механізми взаємодії між процесами і потоками тощо), який дозволив перенести рішення на іншу платформу.

Звичайно, вибір адекватної технології, платформи і т.д. - дуже важлива частина завдання проектування системи. Перед нашою компанією була поставлена ​​задача сполучення існуючої системи електронних платежів з програмним забезпеченням, що підтримує торги на електронній біржі. Наша система була реалізована як документо-орієнтована, грунтувалася на транзакціях і передбачала відкритий програмний інтерфейс. Спочатку ми запропонували програмістам електронної біржі модифікувати своє програмне забезпечення для роботи з цим інтерфейсом, але потім прийняли інше рішення, реалізувавши захищений обмін через файловий сервер, що більшою мірою відповідало ідеології ПО наших контрагентів. Економічний ефект такого підходу продемонстрував: стрункість архітектури програмного комплексу не може бути найважливішим критерієм.

«Складність навіть невеликих проектів досягла того рівня, коли їх зручно і корисно розглядати в якості віртуальних підприємств, що мають своїх власників, свій план роботи і своїх виконавців» [3]

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

У такого підходу є суттєві недоліки. Перш за все, його далеко не завжди вдається застосувати. Організація такого процесу вимагає великої кількості менеджерів різних рівнів, які керували б їм. Вартість проекту виростає і робить його часом нерентабельним для замовника. Крім того, при реалізації однотипних проектів, поставлених «на потік», це можливо, а як бути з інноваційними проектами? Не можна прогнозувати час, необхідний для розробки принципово нового алгоритму. Важко придумати методику, що дозволяє адекватно описати шлях, який ще ніхто не проходив. Зовнішній консалтинг, аудит проекту можуть дещо поліпшити ситуацію, але при відсутності прецедентів і вони, за великим рахунком, безсилі. Звичайно, інноваційні проекти переходять в комерційну стадію, як правило, лише після того, коли наукомістка частина вже реалізована. Однак проблеми, хоча і не пов'язані з необхідністю серйозних наукових досліджень, але які передбачають досить серйозні технологічні розробки, зустрічалися не раз.

Якщо делегувати керівникам проектів додаткові повноваження, що перевищують повноваження менеджерів, лише надають звіти на щотижневих зборах керівництва, і включити цих керівників у бізнес, це багато в чому спростить механізм управління проектами. Використання метафори «віртуального підприємства» має безліч неоціненних переваг: зайняті в індустрії розробки програмного забезпечення люди, як правило, є досить яскравими особистостями, які не уникають відповідальності, а тому така форма роботи може виявитися для них більш комфортною. Крім того, значно спрощується механізм оцінки успішності проекту. Для його оцінки значно легше використовувати технології бюджетування, описані, наприклад, в [6].

Ви не повинні допускати, щоб ви не знали мови, прийнятого в області, якій керуєте »[4]

У проектах, пов'язаних з розробкою програмного забезпечення, роль менеджера не може зводиться до спілкування з замовником і суворому спостереження за «риттям канави» командою підлеглих. Розуміння технологічних проблем, з одного боку і здатність до їх обговорення, з іншого, є неодмінною вимогою, що пред'являються до керівника проекту. Одного разу я спостерігав картину, як знову прийшов керівник проводив збори своєї команди. Справно приходили на збори програмісти досить швидко перестали спілкуватися зі своїм керівником - нічого було обговорювати. По суті, високооплачуваний менеджер середньої ланки грав роль сержанта, заганяє взвод на захід. Досить дороге задоволення, чи не так? На хвилі Internet-буму з'явилася велика кількість керівників проектів, які вміють організувати розробку Web-представництва. Проблеми, що постають при розробці серйозного програмного забезпечення і зазвичай незрівнянно більш складні, припускають наявність в учасників команди значно більшого професіоналізму.

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

Якщо хтось не дивиться, не питає, не аналізує, попросіть його піти »[4]

Байдужа людина руйнує команду - в тому випадку, звичайно, якщо команда зацікавлена ​​в успіху. Але як в умовах стислих термінів, недофінансування, затриманих відпусток і т.д. зберегти зацікавленість в успіху? Взагалі кажучи, Йордан про це вже все пояснив - «ніяк» [1]. Немає універсальних рецептів, які допоможуть зберегти команду. Особливо, якщо її немає. Влаштовуючись на роботу, я жодного разу не чув від опитують мене фахівця, про те, що компанія витратила бюджет проекту, управляти яким мене запрошували, ще півроку тому. Або про те, що відділ розробки укомплектований абсолютно різними - культорологічною, професійно і соціально - людьми, які не в змозі ефективно працювати разом. Про взаємодію між департаментами продажів і розробки можна тільки мріяти. З великим подивом я дізнавався про те, що насправді ніяких стратегічних планів немає, що «партнерські» компанії не дуже зацікавлені в спільному бізнесі і т.д. Декларовані сертифікати ISO, CMM і т.д. - часто лише красиві вивіски для залучення замовників, під якими нічого немає або, в кращому випадку, сертифікат.

При розробці великої системи компанія потрапила в складну фінансову ситуацію. Стало зрозуміло, що протягом двох або трьох місяців не буде чим платити зарплату. Це було тим більше неприємно, що йшла напружена робота, і багато фахівців проводили в конторі по 12-14 годин і без вихідних. Обговоривши стан справ, керівники компанії прийшли до наступного рішення. Зібравши колектив, вони чесно описали становище, визнали свою провину за ситуацію, що склалася, і попросили співробітників потерпіти. Пообіцявши тим, хто вирішить піти, в будь-якому випадку заплатити після виходу компанії з кризи, керівники поставили перед своїми колегами одна умова - прийнявши рішення залишитися, не змінювати його протягом обумовленого терміну. Треба сказати, що нам повірили практично всі співробітники. Проект був врятований.

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

«Неправильне рішення, прийняте раніше, може бути переглянуто пізніше. Правильне рішення, прийняте надто пізно, нічого не може змінити »[4]

У роботі над невеликою системою класу CRM, розрахованої на невелике (до двадцяти) кількість одночасно працюючих користувачів, було вирішено використовувати напрацювання попередніх проектів помітно більшого масштабу. Тому була обрана многозвенная архітектура. Напрацювання дійсно були, але ресурсів для їх адаптації для поточного проекту не вистачало. Занадто пізно зрозумівши помилку, проект в паніці перевели на двухзвенную клієнт-серверну архітектуру. Що вийшла в результаті продукт якось робив те, що від нього очікували замовники, але реально його якість залишала бажати кращого. В кінцевому рахунку доля програмного продукту була сумна: він не був впроваджений, а компанія була змушена виплачувати великий штраф.

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

***

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

література

1. Edward Yourdon, Death March. The Complete Software Developer? S Guide to Surviving Mission Impossible. Projects Prentice Hall, 1997. (є переклад: Едвард Йордан, «Смертельний марш. Повне керівництво для розробника програмного забезпечення по виживанню в безнадійних проектах». Переклад з англ . А.М. Вендрова.

2. Frederick P. Brooks Jr., The Mythical Man-Month. The Essays on Software Engineering. Addison-Wesley, 1975. (Є переклад: Брукс Ф. Міфічний людино-місяць, або Як створюються програмні системи. Переклад з англ. С. Маккавєєва. СПб .: Символ-Плюс, 2001.)

3. Борис Шлаін, «Слабка ланка в бездоганною автоматизації ...». CIO / Керівник інформаційної служби, 2003 № 1.

4. В. Куперштейн, В. Богданов, Сто правил керівників проектів NASA .

5. Alistair Cockburn, «Humans and Technology Technical Report, TR 99.04, Oct.1999 7691 Dell Rd, Salt Lake City, UT 84121, USA. (Є переклад: Алістер Коуберн, «Кожному проекту своя методологія». http://www.maxkir.com/sd/methyperproject_RUS.htm .)

6. Олексій Суботін, «Контроль бюджету проекту за графіками? Освоєного обсягу?». // «Директор інформаційної служби», 2002 №11.

Олександр Епштейн ( [email protected] ) - незалежний консультант і розробник програмного забезпечення (Москва).