vit_r (vit_r) wrote,
vit_r
vit_r

Про графики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tags: business_tales, it, management, qa, quality, ru, se
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.
  • 21 comments