vit_r (vit_r) wrote,
vit_r
vit_r

Секреты менеджмента

А нужно обязательно дорогостоящего, или подойдет просто хороший?
pvn123 тут



Думаю, все уже прочитали эпический пост про программиста, пославшего нафиг подрядчиков с менеджерами и решившего всё запрограммировать самостоятельно, а также дискуссию по этому поводу у metaclass и в вечернем противогазе

Я был на позиции всех участников этого спора. И за подрядчика, пытающегося добыть информацию, и за технического ответственного у заказчика, убеждённого, что подрядчика надо срочно посылать нафиг, и за менеджера, объясняющего программисту, почему нужно делать то, что нужно, а не то, что он считает нужным. (Последнее, кстати, самое фиговое, но об этом как-нибудь в другой раз.)

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

Мой опыт показывает, что основная проблема в том, что из-за ошибочного отнесения программизма к точным наукам никто не понимает, как использовать математику.

Да, в индустрии говорят о занятой памяти, скорости доступа, молятся на букву «O», особо продвинутые знают страшные слова вроде «цикломатическая сложность» и, даже, могут постараться и выдать число. Но всё это пустое. Единственная интересная метрика из популярных - function points. Правда для того, чтобы из цифр что-то полезное извлечь, нужно иметь базу по многим годам и многим проектам для тех же задач, тех же методик и того же персонала.

Между тем, практически всегда можно найти метрики, которые дают однозначный ответ на поставленный вопрос. Нужно просто понять, чем измерять неизмеримое напрямую.

Процент пустых полей в базе может показать, насколько пользователи понимают, что от них хотят. Количество открытых вопросов в переписке, разложенное по неделям, ясно показывает, что проект идёт вразнос. Поиск словосочетания «требуется обсудить» в подписанной и принятой к исполнению спецификации даёт диаграмму, которая даже высшему менеджменту наглядно демонстрирует, что у нас не водопад, а катастрофа. И простое вычитание якобы исправленных ошибок из количества ошибок, найденных в новом релизе, показывает самому гениальному программисту, что он занимается откровенным вредительством.

В принципе, в этом нет ничего сложного. Так создают статьи в биологии, психологии или экономике. Нужно просто правильно поставить вопрос и посмотреть, где копать.

Однако, высоколобые специалисты по ИТ, которое «информационные технологии», якобы отвечающие за качество софта тестеры, отэмбеашенные менеджеры и сертификационные бюрократы по процессам и формулярам ходят по развалам данных, но даже не догадываются об этом. Вот и получается вместо предметного разговора религиозно-софистический диспут.

Естественно, от одной демонстрации диаграммок и таблиц на бумаге редко когда что-то кардинально меняется. Но даже в самом запущенном случае люди могут просто договориться «Да, мы идём ко дну, но по политическим соображениям не будем этого не замечать. Давайте лучше пригласим цыганский оркестр и закупим шампанского.»
Tags: agile, business_tales, it, management, motivation, psychology, qa, quality, ru
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 28 comments