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

Ігор Ашманов

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

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

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

• Ну, не знаю, у мене на машині все працює.
  Коментар: це неправда. Тобто, звичайно, щось працює - після серії магічних пасів, недоступних користувачеві і тестувальникам.
• Так у вас просто "Вінди" криві.
  Коментар: це не має ніякого відношення до справи. У більшості користувачів в світі "Вінди" - криві, а прикладні програми все-таки працюють.
• Спробуйте перезапуститися. Думаю, все запрацює.
  Коментар: це малоймовірно, хоча можливо. Але програма повинна працювати і без перезапуску.
• Як справи в проекті? Робота ведеться!
  Коментар: "Працюємо" - звичайна відповідь розробника на питання менеджера. Допомагає "відбити" дві третини, а то і чотири п'ятих запитів про хід проекту. Сам по собі цей відповідь - не кримінал, і насправді в розробці бувають періоди завзятої роботи "від забору до обіду", коли результатів не видно. Але часте повторення цієї формули підозріло - вона може служити і для приховування вже вималювалися проблем з термінами і трудомісткістю, які розробник сподівається вирішити сам, не доводячи до начальства.
• Я вже тиждень ночами працюю, а ви мене сваритеся за зрив терміну.
  Коментар: нічна робота - це зовсім не доблесть. Швидше за все, просто у програміста склався такий режим (що часто буває), а в добу однаково виходить 8-10 робочих годин. Навіть якщо і була б переробка, то це недолік організації робіт.
• Не можна підпускати до проекту цих маркетоідов, які нічого не розуміють в технологіях.
  Коментар: маркетоіди не дають програмувати всякі цікаві штуки і вносять занадто багато приземлених комерційних вимог.
• Ці менеджери знову почнуть радитися, а мені працювати потрібно.
  Коментар: дійсно, часто наради не мають сенсу, але зовсім без них не можна. А програмісти із задоволенням беруть участь в одних нарадах, де йдуть обговорення взагалі і придумуються всякі класні ідеї, і не люблять інші - ті, на яких настає занадто велика ясність щодо стану справ і виконання планів.
• Чого там планувати, я швидше зроблю і все вже буде працювати.
  Коментар: це неправда. Швидше за все, буде зроблено не зовсім те і непрацююче. А термін доведення виявиться довжиною в цілий проект.
• Планувати розробку безглуздо, життя все одно багатшими. Програмні проекти завжди зривають терміни, тому що це складне і творча справа, начебто наукових досліджень.
  Коментар: це міф. При правильному проектуванні і плануванні терміни розробки ПО можливо витримати і це потрібно робити.
• Наймати персонал повинен тільки технічний менеджер проекту, тому що йому потім з ними працювати.
  Коментар: це часто призводить до невблаганного спрацьовування Закону Паркінсона - найму по знайомству непотрібних, слабких або неконтрольованих співробітників. Наймати розроблювачів повинен вищий менеджмент і по можливості через кадрове агентство, а технічний менеджер - накладати вето при необхідності.
• Якщо все зробити загальним чином, ми отримаємо не тільки рішення приватної завдання, а й готовий програмний продукт, який будемо продавати іншим, і таким чином все окупимо.
  Коментар: це просто приємні фантазії. Розробка готового продукту коштує приблизно в три рази дорожче програми для власних потреб (див. "Міфічний людино-місяць" Фредерика Брукса). Крім того, ніхто ж не вивчав ринок на предмет з'ясування, а чи потрібен такий продукт, і скільки у нього сильних конкурентів.
• До п'ятниці готово не буде, але в понеділок - точно. Або у вівторок.
  Коментар: швидше за все і у вівторок нічого не буде. У кращому випадку буде не готова версія, а щось для показу з рук з поясненнями на пальцях, як все буде потім.
• На певний час готове не буде, тому що згорів жорсткий диск і пропала робота за тиждень (місяць).
  Коментар: швидше за все, це неправда. Диск дійсно згорів, але причина зриву термінів не в цьому. Крім того, якби робота щодня архівувалася, проблеми б в будь-якому випадку не виникло.
• Термін зірваний - а що ви хотіли? З самого початку було ясно, що ресурсів не вистачає.
  Коментар: це точно неправда. На початку проекту ніхто не підняв тривоги, що мало ресурсів. І в середині проекту - теж. Це просто найпоширеніша "відмазка".
• Програма добре документована на мові Сі.
  Коментар: програмістська жарт "для своїх", що відображає той сумний факт, що ніхто не писав коментарів і документації до програм і не буде писати, якщо не примусити твердою рукою.