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