Правила Ашманова

1. Про управління програмістами
2. Поширені міфи про розробку програмного забезпечення
3. Правила, які корисно знати менеджеру
4. висновки
5. додаток

Ігор Ашманов

© "Ашманов і Партнери"

Увага, вийшло продовження: Правила Ашманова. Частина 2. Про управління проектами

Даний звід висловлювань призначений для керівників, яким волею долі довелося займатися новим для себе справою - управляти тим або іншим "програмістських" проектом (створенням інформаційної системи підприємства, розробкою сайту, і т. П.).

Досвідченій людині сказане нижче може здатися набором простих і давно відомих істин. Я і не збираюся претендувати на авторство всіх наведених нижче правил.

Однак початківці менеджери програмних проектів часто не знають найпростіших речей - наприклад, того простого факту, що не можна вірити термінів, званим програмістами. Військові статути і Правила дорожнього руху також виглядають просто, але вони "писані кров'ю".

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

Ось ці найпростіші речі і зібрані тут у вигляді зводу правил. Ось найперше з них:

Перше правило Ашманова. Не буває технічних проблем. Бувають тільки людські, тобто організаційні.

Я не даю тут технічних рад щодо управління проектами, правил планування та документування, процедур тестування і випуску. Про все це написано гори спеціальної літератури, в тому числі класична книга Фредеріка Брукса "Міфічний людино-місяць".

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

Про управління програмістами

Я особисто дуже поважаю і люблю розробників програмного забезпечення - програмістів, однак в поводженні з ними потрібно бути обережними і певні правила.

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

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

Поширені міфи про розробку програмного забезпечення

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

Тому розмови про унікальність розробників ПЗ, специфіці управління програмістських проектом, особливих шляхах бізнесу - завжди дуже підозрілі.

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

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

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

Потрібно пам'ятати, що розробник ПЗ - це інженер, а в бізнесі високих технологій виграють не інженери, а бізнесмени і менеджери. Як і всюди.

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

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

Правила, які корисно знати менеджеру

Правило 2. Технічний жаргон нічого не означає.

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

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

Правило 3. Розробники завжди називають невірні терміни.

Не можна вірити термінів, які називають програмісти. Зазвичай їх слід множити на Пі. Іноді (рідко) - ділити на Пі. Вибір правильного дії керівника над званими термінами залежить від особистості розробника. Це знання приходить до менеджера тільки після декількох експериментів саме з цим розробником.

Правило 4. Розробнику властивий вроджений оптимізм.

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

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

Правило 5. Програміст відчуває пристрасть до узагальнення.

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

І в цьому ж - серйозна загроза бізнесу. Якщо дати розробникові волю, розробка спільної платформи відніме 100% часу і грошей, і продукт ніколи не вийде на ринок.

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

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

Правило 6. Не можна робити "по-доброму".

Всякий програміст свою пристрасть до узагальнення виправдовує похвальним бажанням нарешті все зробити по-хорошому. Точно так же системний адміністратор завжди просить грошей на найкращу техніку та найдорожче програмне забезпечення від Oracle. Робити по-хорошому - теоретично неправильно і практично шкідливо для бізнесу. Потрібно робити так, щоб все працювало, задовольняло клієнтів (рівно на рівні ціни продукту) і бізнес розвивався.

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

Правило 7. Прімінаніе трави може відняти будь-яку кількість часу.

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

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

Правило 8. Розробник не цікавиться бізнесом, він - типовий автор.

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

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

Це нормально, так як авторські мотиви - дуже потужні і їх можна правильно використовувати з великою користю для компанії.

висновки

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

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

додаток

Словник ненормативної лексики програміста

Вчіться розуміти програмістів. "Ну, не знаю, у мене на машині все працює!" - "Планувати розробку безглуздо, життя все одно багатшими!" - "До п'ятниці готово не буде, але в понеділок точно. Або у вівторок!" - "Програма добре документована на мові C".

Вийшло продовження: Правила Ашманова. Частина 2. Про управління проектами

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