Про графики

[vit_r]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comments

[raydac.livejournal.com]

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

[vit-r.livejournal.com]

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

Авралы тут тоже бывают. И, даже, в крупных фирмах.

[raydac.livejournal.com]

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

[alexott.livejournal.com]

у больщинства программистов (тех кого я знаю в германии) в контракте нет оплаты переработок. Это только консультанты будут получать пропорционально отработанным часам :-)
Правда хочу сказать, что за 5 лет моей работы я только пару раз работал до позднего вечера, и один раз в выходные - обычно когда что-то критическое найдено перед релизом

[raydac.livejournal.com]

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

[vit-r.livejournal.com]

у больщинства программистов (тех кого я знаю в германии) в контракте нет оплаты переработок.

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

Насчёт контрактников тоже весело бывает. Дойче Бан формально считает цену за день, говоря, что всё, что меньше восьми - не день, а то, что больше - за свой счёт. А в Дойче Телекоме после того, что я ответил, что готов работать и по субботам, но за плюс 20 к ставке, тётя посмотрела на меня как на врага народа.

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

[vit-r.livejournal.com]

Зависит от условий и талантов менеджеров. Формально запрещено работать наёмным больше 10 часов в день, больше 6 без перерыва, и лишние часы без подтверждения руководства. Практически полно случаев, когда люди делают 12 часов, а пишут 8. Зависит только от любви людей к труду, и их возможностей устроиться на ту же зарплату в нормальное место.

[raydac.livejournal.com]

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

[vit-r.livejournal.com]

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

[raydac.livejournal.com]

вот поэтому я и думаю съе..ть из раши, так как кпд перевода времени в деньги тут абсолютно неадекватное, а даже не из-за путина или зомбированного ссср

[alexott.livejournal.com]

кстати, напиши мне почтой, меня недавно антивирусники спрашивали про людей

[alexott.livejournal.com]

подпишусь под каждым словом про большие концерны...

[serg70p.livejournal.com]

Параллельные преобразования огромных массивов данных нужны редко
- так уж редко????

[vit-r.livejournal.com]

Если убрать науку, которая играется с данными только ради игры, и стартапы, которые просто сжигают деньги инвесторов, то есть оставить только промышленные и коробочные приложения, приносящие деньги, то да: или такие преобразования не нужны вовсе, или они уже сделаны на библиотечном или аппаратном уровне.

[serg70p.livejournal.com]

то есть БД или просто 100 терабайтовый фильм, уже не попадают в эту классификацию?

[vit-r.livejournal.com]

Кому и зачем нужен фильм на 100 терабайт?

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

[serg70p.livejournal.com]

аватар занял ровно в 20 раз больше. просто любой фильм -это такой размер.
------------
абсолютный размер, вообще ничего и нио чём. интересен относительный.
просто сопоставьте например 2 метра, и объём кешей проца, или одной решалки -хоть в куде хоть в какомнидь аэрэме.

а это уже про большинство.

[vit-r.livejournal.com]

Как это относится к написанному в посте?

[serg70p.livejournal.com]

пост классный, с выводами согласен.
смутила только эта строка -
Параллельные преобразования огромных массивов данных нужны редко
------------
для меня массив данных, это и фильм, и разборка геном последовательностей.

[vit-r.livejournal.com]

Имелось ввиду, естественно, программирование алгоритмов параллельных преобразований.

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

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

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

[serg70p.livejournal.com]

я занимался программирование алгоритмов параллельных преобразований. Как раз в вебе. я не про геномы, а про массивы, там в строке можно и так написать.