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