Даний звід висловлювань призначений для керівників, яким волею долі довелося займатися новим для себе справою - управляти тим або іншим "програмістських" проектом (створенням інформаційної системи підприємства, розробкою сайту, і т. П.).
Однак початківці менеджери програмних проектів часто не знають найпростіших речей - наприклад, того простого факту, що не можна вірити термінів, званим програмістами. Військові статути і Правила дорожнього руху також виглядають просто, але вони "писані кров'ю".
Багато разів бачили ми зрив термінів, провал проектів. Бачили бізнесменів, з готовністю вкладали гроші в нову технологію, що вражає уяву - без розуміння ринку, бізнес-планів та навіть приблизних результатів і термінів робіт. Я і сам здійснював безліч подібних помилок за 15 років роботи в індустрії виробництва програмного забезпечення.
Ось ці найпростіші речі і зібрані тут у вигляді зводу правил. Ось найперше з них:
Перше правило Ашманова. Не буває технічних проблем. Бувають тільки людські, тобто організаційні.
Я не даю тут технічних рад щодо управління проектами, правил планування та документування, процедур тестування і випуску. Про все це написано гори спеціальної літератури, в тому числі класична книга Фредеріка Брукса "Міфічний людино-місяць".
Однак посадові інструкції і правильні процедури - далеко не все. При запуску проекту керівник в першу чергу вступає в людські стосунки з колегами, виконавцями, підлеглими. Ці відносини складні, незвичні і часто можуть просто поставити в глухий кут, якщо не знати всього декількох простих правил.
Про управління програмістами
Я особисто дуже поважаю і люблю розробників програмного забезпечення - програмістів, однак в поводженні з ними потрібно бути обережними і певні правила.
Управління програмістами - не магія. Управляти програмним проектом може навіть гуманітарій. Але для цього обов'язково потрібно взагалі вміти управляти людьми і проектами. Як і в будь-якій галузі, менеджеру достатньо знати деякі особливості технологічного процесу і не піддаватися "міфам індустрії". Все інше залежить від звичайного вміння менеджера налагодити роботу.
Міфи. Управління програмістами має особливості, ускладнені міфами і ілюзіями навколо програмування. Ці міфи охоче підтримуються розробниками і продавцями комп'ютерних послуг. Основною причиною міфів є протиріччя між очевидною інтелектуальністю і складністю роботи з одного боку, і зовсім звичайними властивостями персоналу і проектів - з іншого боку. Незалежність від міфів приходить з досвідом і знанням.
Поширені міфи про розробку програмного забезпечення
Міф про унікальну специфіку програмного забезпечення. Виробництво програмного забезпечення не є особливим бізнесом, що б там не говорили самі розробники або продавці інформаційних систем. Воно не більше особливе, ніж харчова промисловість або косметологія. Закони розвитку і окупності проектів при розробці ПЗ, інтернет-сайтів та корпоративних інформаційних систем - ті ж самі, що й скрізь.
Тому розмови про унікальність розробників ПЗ, специфіці управління програмістських проектом, особливих шляхах бізнесу - завжди дуже підозрілі.
Міф про велич програміста. Розробник програмного забезпечення - НЕ оракул, пророцтва якого бізнесмен повинен слухати з захопленням. Дійсно, зовні будь-, навіть середній програміст виглядає, як дорослий, розумний і відповідальна людина - він високоосвічена, займається складною розумовою працею, володіє термінологією, вміє поставити завдання і обгрунтувати запит на виділення ресурсів. При цьому на ділі він постійно проявляє себе як малолітній двієчник - не говорить всієї правди, помиляється з термінами, зриває проекти, згортає з прямого шляху і розважається за рахунок роботодавця.
Якщо в проекті розробники грають першу скрипку, ймовірність краху проекту - висока. Вірна ознака такого становища - коли менеджер високого рівня, непрограмістів, з помітною невпевненістю розповідає про те, що все йде нормально і поточний етап проекту являє собою важливі внутрішні технічні поліпшення, які на наступних етапах дозволять здійснити прорив.
Потрібно пам'ятати, що розробник ПЗ - це інженер, а в бізнесі високих технологій виграють не інженери, а бізнесмени і менеджери. Як і всюди.
Міф про магічну силу технології. Нова, складна, вражаюча технологія не обов'язково приведе до успіху. На щастя, сьогодні це вже не потрібно нікому спеціально доводити. Будь-яка технологія може стати успішним продуктом, а може просто привести до розтрати грошей інвестора. Джерела успіху проекту завжди лежать поза сферою технологій - в сфері бізнесу.
Крім того, потрібно пам'ятати, що дійсно унікальні технології виникають дуже рідко, і з великою ймовірністю зараз точно така технологія вже обговорюється, розробляється або навіть продається десь ще.
Правила, які корисно знати менеджеру
Правило 2. Технічний жаргон нічого не означає.
Програмісти використовують досить розвинений технічний жаргон, в тому числі на нарадах і в доповідних записках. Відомо, що будь-який жаргон служить пізнанню своїх і заплутування чужих. Жаргон програмістів - не виняток, а ворожим чужаком для програміста часто служить його начальство.
Правило 3. Розробники завжди називають невірні терміни.
Не можна вірити термінів, які називають програмісти. Зазвичай їх слід множити на Пі. Іноді (рідко) - ділити на Пі. Вибір правильного дії керівника над званими термінами залежить від особистості розробника. Це знання приходить до менеджера тільки після декількох експериментів саме з цим розробником.
Правило 4. Розробнику властивий вроджений оптимізм.
Типова ознака необ'їждженого розробника-оптиміста - самовпевненість і гарячність, прагнення піти і зробити, а не сісти і запланувати.
Правило 5. Програміст відчуває пристрасть до узагальнення.
Програміст завжди всіма силами прагне зробити роботу найбільш загальним способом, щоб потім тільки налаштовувати та прилаштовувати готову систему. У цьому - суть програмування і його сила.
І в цьому ж - серйозна загроза бізнесу. Якщо дати розробникові волю, розробка спільної платформи відніме 100% часу і грошей, і продукт ніколи не вийде на ринок.
Баланс між узагальненням і поточними вимогами ринку досягається досвідом і міркуваннями бізнесу. Програмістам довіряти тут абсолютно безглуздо, як безглуздо обговорювати з п'яницею сімейний бюджет.
Правило 6. Не можна робити "по-доброму".
Всякий програміст свою пристрасть до узагальнення виправдовує похвальним бажанням нарешті все зробити по-хорошому. Точно так же системний адміністратор завжди просить грошей на найкращу техніку та найдорожче програмне забезпечення від Oracle. Робити по-хорошому - теоретично неправильно і практично шкідливо для бізнесу. Потрібно робити так, щоб все працювало, задовольняло клієнтів (рівно на рівні ціни продукту) і бізнес розвивався.
Вірна ознака роботи в стилі "по-доброму" - наполеглива робота з "ядром", затримки з реалізацією конкретної запланованої функціональності і зрив термінів виходу продукту.
Правило 7. Прімінаніе трави може відняти будь-яку кількість часу.
Програміст завжди прагне задовольнити свою потребу в озброєності - максимально облаштувати робоче місце, тобто створити інструментарій, встановити найостанніше програмне забезпечення, найсучаснішу техніку. Якщо дати йому волю, він витратить на це 100% робочого часу, причому зуміє довести начальству необхідність такої роботи.
Вірна ознака такого перманентного облаштування - напіврозібрані комп'ютери на робочих місцях і незвичайні, нестандартні програми на цих комп'ютерах.
Розробник в середньому не прагне допомогти організувати і розвинути бізнес, саме тому він не любить тестування, вважає користувачів ідіотами, тому його важко змусити документувати і підтримувати вже зроблені системи і програми.
Доводиться працювати з тим, що є. Зі сказаного випливає практична неможливість перевиховання розробників, системних адміністраторів і середніх технічних менеджерів в діловому дусі. Цього і не потрібно. Замість перевиховання потрібно розуміння мотивів і звичок, і працюють процедури планування, виконання та контролю, що зберігають свободу мислення і залишають простір для творчості.
додаток
Вчіться розуміти програмістів. "Ну, не знаю, у мене на машині все працює!" - "Планувати розробку безглуздо, життя все одно багатшими!" - "До п'ятниці готово не буде, але в понеділок точно. Або у вівторок!" - "Програма добре документована на мові C".
Щоб проект вдався, треба знати і виконувати ряд простих правил. Однак багато менеджерів сподіваються, що пронесе і так.
Правильні проекти, і що для цього потрібно. Неправильні проекти, і як їх лікувати.
Слідкуйте за нашими новинами
Будь ласка, спробуйте ще раз