vit_r

Ценность менеджера определяется количеством уровней до вершины. Понимание ситуации - количеством уровней от земли.

Хозяин фирмы из двух инженеров, секретарши и четверти студента гораздо более руководитель, чем какой-нибудь промежуточный матрично-структурный-проджект-связун, болтающийся между начальниками клиентов, начальником разработчиков, погонщиком из Бангалора и практиканткой из финансового отдела.

Настоящий начальник - это тот, у кого на входе обмен чего-то на деньги и на выходе тоже обмен чего-то на деньги. Включая интерфейсы с клиентами, подрядчиками и работниками. Когда бумажки обмениваются на бумажки - это работа секретарская. Даже если у матричного миллионные бюджеты и якобы сотни людей в подчинении. Тем более, если бумажки должны быть завизированы подписью вышестоящего руководителя.

Это тоже умения, навыки и искусство, но область меня совершенно не интересует и менеджментом её называют по недоразумению.

Цифры в айти бесполезны и всегда проигрывают экспертным оценкам. Кроме одного случая, когда цифры поставлены в ряд и на его основе построен график тенденций.

Пара почти не отредактированных реальных диалогов.

Мелкая фирма. За столом по формальным визиткам тестер, секретарша и маркетолог.

• - Продукт через месяц готов не будет. Вот график. Слева - количество проблем, внизу - время. Вот это число сдачи. Чтобы нормально выйти к клиентам мы должны быть хотя бы в три раза ниже.
• - Ты уверен?
• - Вот график. Вот прямая. Вот точка, где она уходит в ноль. Это плюс месяц, если никаких неожиданностей не будет.
• - Ускорить можно?
• - Как? Люди на пределе. Если будут работать больше или выйдут в выходные, только ошибок лишних наделают. Ну, можно свободных людей на тестирование посадить. Ошибок найдут больше, но с разработчиков это снимем.
• - У нас кто-нибудь есть?
• - Хм... N, ещё M. И у дизайнеров загрузка не полная. Хорошо. Через два часа пойдём, я тебе покажу народ, объяснишь что делать.
• - Хорошо.
• - Так. Я тебя правильно понял: мы переносим рекламную компанию на две недели, а тут выпускаем продукт? Это точный срок?
• - Я бы прибавил одну неделю. А бета тест начал бы вот тут. Если мы обрежем функциональность следующим образом...

Крупный концерн. За столом по формальным визиткам менеджер по одной фигне и менеджер по другой фигне.

• - Продукт через месяц готов не будет. Вот график. Слева - количество проблем, внизу - время. Вот это число сдачи. Чтобы нормально сдать проект мы должны быть хотя бы в три раза ниже.
• - Не может быть.
• - В смысле?
• - У нас уже почти всё готово. Столько ошибок быть не может.
• - Хорошо. Вот табличка с ошибками. Идём вниз. Вот количество строчек. Минус одна на заголовок.
• - Не может быть. Тут что-то не правильно.
• - В смысле?
• - Вот это уже сдали. Тут что за ошибка?
• - Это? В соседней колонке написано, что X не правильно, потому что не заполнено поле Y. А без этого весь X смысла не имеет.
• - Не может быть. Поле Y не может быть пустым.
• - Так. Ага. У нас тысяча триста таких случаев.
• - Нет. Десять - двадцать я ещё поверю. Но тысяча? Не может быть.
• - Почему? Пользователи не заполняют. И программа F это не проверяет. К тому же сама генерит кучу ошибок. Проверим все вручную?
• - Нет. Хорошо. Тысяча. Что-же делать? Что же делать?
• - Можно исправить софт F, чтобы он ошибки не прятал, а находил и сообщал пользователям. И не собирать мусор.
• - Нет. Сдавать через месяц. И F никто исправлять не будет. У них времени нет.
• - Там же ерунда. Дайте нам. Мы за неделю все ошибки поправим.
• - Так нельзя! Это же другой отдел.
• - Ну так отправьте назад и скажите, что пока ошибки не исправили, мы работать не можем.
• - Нельзя! Нам приказано использовать F. У нас Процесс.
• - Ну так мусор на выходе: каждая третья запись в результатах - лажа.
• - Почему мусор? Две трети же правильны!

Ну и так далее.

Проект, конечно, сдан. И, конечно, в срок. И, конечно, успешно. А график, конечно, совсем не улучшился. И даже вырос совсем не в ту сторону.

А как такое чудо произошло, это большая корпоративная тайна и высокое искусство проектного менеджмента. Удивительно, но очень много людей играют в это всерьёз и, даже, этим хвастаются.

Насчёт прошлого поста пара комментариев из комментариев.

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

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

Сейчас попробую собрать обещанную картинку, а потом сажусь изучать R.