November 30th, 2012

vit_r

Про графики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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