Критерии оценки — результат переговоров руководителя и исполнителя. Ни один уважающий себя менеджер не подпишется под нереальными сроками/трудозатратами. Если Вы, конечно, об этом.
Мнение, конечно, интересное. Но, я пока не знаю альтернатив, которые позволили бы привести к общему знаменателю (провести сравнительную хотя бы экспертную оценку) разных проектов оп разработке ПО. А делать это необходимо.
Мне всегда представлялось, что ПО — продукт командной работы. А в командной работе важен общий результат, а не то сколько километров пробежал форвард, сколько ног сопернику переломал защитник и сколько раз прыгал за мячом вратарь. Все это не важно, если команда проиграла.
Вводя индивидуальные KPI вы еще разжигаете конкуренцию и убиваете командную синергию.
Моя ключевая мысль: у менеджера есть свои личные цели, достижение которых обусловлено успешностью проекта. И перекладывать на Васю ответственность за их достижение он никогда не станет.
Человечеству известны два вида деятельности. Репродуктивная деятельность (труд) является слепком, копией с деятельности другого человека либо копией своей собственной деятельности, освоенной в предшествующем опыте. Такая деятельность, как, например, труд токаря в любом механическом цеху, или рутинная повседневная деятельность менеджера-управленца на уровне раз и навсегда усвоенных технологий. Продуктивная деятельность (творчество) — деятельность, направленная на получение объективно нового или субъективно нового (для данного работника) результата.\
Спасибо. Оч. интересный опыт.
Возможно мой пост слишком категоричен. Конечно можно и конвейер построить. Только вот вопрос, насколько он будет конкурентоспособен на рынке?
Про сайты полностью согласен. Это массовое производство.
Подавляющее большинство программ, которые пишут сейчас программисты это типичные сайты.
ИМХО, это не так. Goole, Amazon, Yandex, Mail.ru — это не сайты. Это сервисы. Порой наукоемкие и уникальные. А еще есть продуктовая разработка и автоматизация бизнеса.
Спасибо. Отличный конкурс. Захотелось внести свой вклад.
Покопался в долговременной памяти. И вот, что показалось самым ярким уроком в практике работы с людьми.
Много лет назад имел честь работать под руководством пару лет присутствовать на еженедельных оперативных совещаниях и несколько раз пообщаться с Ю.А. Мазжориным. И вот какую историю о нем рассказал мне по секрету один из его заместителей.
Заседала межведомственная комиссия по допуску изделия (так в отрасли называли все, что летало и не летало) к ЛКИ (летно-космическим испытаниям). В комиссии участвовал весь цвет советского космоса: генералы, генеральные конструкторы, ведущие ученые. Стоимость одного изделия исчислялась десятками миллионов советских ($1 = 64 коп.) рублей, поэтому дискутировали всю ночь (помним, что риск = вероятность фейла * потери). В конце концов, все, кроме Мозжорина, подписали решение о допуске. А Юрий Александрович, который отстаивал на комиссии отрицательное заключение ученых ЦНИИМАШ, приложил листок с особым мнением.
Пуск прошел «за бугор» :(
Что бы сделал обычный советский руководитель? Правильно. Отправился бы в Политбюро со словами «а я предупреждал!». Что сделал выдающийся руководитель. Подписал решение о допуске и забрал «особое мнение».
Какой урок я извлек из этой истории?
Командная работа гораздо важнее ЧСВ даже собственной правоты здесь и сейчас.
…на практике это была ежегодная неделя идиотизма, когда каждый инженер, ломая голову от тоски и безысходности, высасывал из пальца нечто, что было бы и не слишком абстрактно типа «работать хорошо». […] И каково же было мое удивление и почти шок, когда на «прожженном звоном монет» буржуинском Западе я столкнулся с точно таким же бредом — почти во всех больших фирмах всех программистов заставляют писать ежегодные планы самим себе.
Да, помню.
Члены ВЛКСМ должны были писать личные комплексные план (ни разу не видел, чтобы составлялись больше чем на год) и сдавать по ним ленинские зачеты. Для старших товарищей были социалистические обязательства и профсоюзные собрания с отчетом об их выполнении.
Позднее в уважаемой компании PwC я имел дело с аналогом подобных соцобязательств, который назывался «план личностного развития», под выполнение которого резервировался определенный процент часов (до 40%) годового рабочего времени программиста.
Разумеется, все зависело от реализации. Можно было, конечно, в этих планах писать «идиотизм», а можно – «освоить новую технологию XXX», «изучить лучшие практики YYY», «провести исследования перспективности нового направления ZZZ».
В такой постановке считаю подобные соцобязательства благом и для работодателя и для наемного работника. По сей день практикуем ежегодную аттестацию сотрудников, одним из результатов которой является рекомендации по личному развитию.
Для меня стало совершенно очевидно, что весь проект пойдет в корзину.
Дальше был не менее бредовый и не менее большой проект…
Был еще один безумный по тем временам проект…
Я был, как уже написал выше, просто в шоке и в состоянии легкого нервного срыва.
Крепостное право, вроде бы, отменили. Есть ли смысл тратить свою жизнь на мертворожденные проекты и работу с неадекватными работодателями?
У неискушенного читателя может сложиться впечатление, что выбор правильного набора инструментов, существенно повышает вероятность успеха.
ИМХО, это не совсем так.
50 лет назад сложные программные системы создавались без wiki, трекеров, календарей с напоминалками и даже (о ужас!) с проектной документацией на бумаге. Несмотря на постоянное появление все новых и новых инструментов поддержки разработки, согласно статистике, приведенной Демарко, средняя производительность в программостроении растет всего лишь на 3-5% в год.
Это происходит от того, что 80% времени программист работает головой и только 20% руками. А для повышения производительности работы мозга инструментов пока не придумали. Так что потенциал повышения эффективности работы программистов при помощи инструментов не превышает 20%.
ЗЫ. Не забудьте учесть затраты на развертывание, освоение и поддержку инструментария.
Все сугубо, ИМХО. «Правильной дорогой идете товарищи» (с) Одна из проблем сегодняшнего программирования, то, что объектом является аристотелева вещь с фиксированным набором свойств. Вот один из примеров, почему это сильно усложняет программирование сложных систем.
Человек рождается с очень ограниченным набором свойств: иметь возраст, вес, рост, пищать, питаться и портить подгузник. Время идет, и он приобретает новые наборы свойств: ученик школы, покупатель, пассажир, солдат, студент, наемный работник, предприниматель, супруг, родитель и т.д. А возможно и не приобретает. Например, не каждый человек служит в армии, учится в вузе, женится и становится отцом или предпринимателем. Или утрачивает. Например, закончил учиться, отслужил в армии или развелся. Следовательно, один и тот же объект должен иметь возможность принадлежать разным классам и этот набор классов должен быть динамическим, т.е. изменяться в ходе эволюции объекта и самой программной системы. На набор классов, к которым относится объект, как правило, накладываются ограничения. Например. Чтобы стать солдатом, человек должен достичь 18 лет. А если человек студент то для того, чтобы стать мужем, необходимо сдать сопромат.
То, что вы описали, как я понял, похоже на путь к решению этой проблемы. Следующий шаг — осознать, что свойство != имя + значение, а является полноценным объектом, который проявляется во взаимодействии со свойствами других вещей.
Как-то, так.
Что измеряете, то и получите.
Мне всегда представлялось, что ПО — продукт командной работы. А в командной работе важен общий результат, а не то сколько километров пробежал форвард, сколько ног сопернику переломал защитник и сколько раз прыгал за мячом вратарь. Все это не важно, если команда проиграла.
Вводя индивидуальные KPI вы еще разжигаете конкуренцию и убиваете командную синергию.
Так, для маленьких и должен быть подростковый текст. Поскольку Брукса и Демарко они никогда «не осилют — многа букав».
Как-то, так.
Возможно мой пост слишком категоричен. Конечно можно и конвейер построить. Только вот вопрос, насколько он будет конкурентоспособен на рынке?
ИМХО, это не так. Goole, Amazon, Yandex, Mail.ru — это не сайты. Это сервисы. Порой наукоемкие и уникальные. А еще есть продуктовая разработка и автоматизация бизнеса.
Покопался в долговременной памяти. И вот, что показалось самым ярким уроком в практике работы с людьми.
Много лет назад имел честь
работать под руководствомпару лет присутствовать на еженедельных оперативных совещаниях и несколько раз пообщаться с Ю.А. Мазжориным. И вот какую историю о нем рассказал мне по секрету один из его заместителей.Заседала межведомственная комиссия по допуску изделия (так в отрасли называли все, что летало и не летало) к ЛКИ (летно-космическим испытаниям). В комиссии участвовал весь цвет советского космоса: генералы, генеральные конструкторы, ведущие ученые. Стоимость одного изделия исчислялась десятками миллионов советских ($1 = 64 коп.) рублей, поэтому дискутировали всю ночь (помним, что риск = вероятность фейла * потери). В конце концов, все, кроме Мозжорина, подписали решение о допуске. А Юрий Александрович, который отстаивал на комиссии отрицательное заключение ученых ЦНИИМАШ, приложил листок с особым мнением.
Пуск прошел «за бугор» :(
Что бы сделал обычный советский руководитель? Правильно. Отправился бы в Политбюро со словами «а я предупреждал!». Что сделал выдающийся руководитель. Подписал решение о допуске и забрал «особое мнение».
Какой урок я извлек из этой истории?
Командная работа гораздо важнее
ЧСВдаже собственной правоты здесь и сейчас.ЗЫ. Это о «Работайте с людьми вдолгую».
Не совсем так.
«Члены ВЛКСМ, достигшие 28-летнего возраста и не избранные в руководящие комсомольские органы, снимаются с комсомольского учета и выбывают из ВЛКСМ».
Да, помню.
Члены ВЛКСМ должны были писать личные комплексные план (ни разу не видел, чтобы составлялись больше чем на год) и сдавать по ним ленинские зачеты. Для старших товарищей были социалистические обязательства и профсоюзные собрания с отчетом об их выполнении.
Позднее в уважаемой компании PwC я имел дело с аналогом подобных соцобязательств, который назывался «план личностного развития», под выполнение которого резервировался определенный процент часов (до 40%) годового рабочего времени программиста.
Разумеется, все зависело от реализации. Можно было, конечно, в этих планах писать «идиотизм», а можно – «освоить новую технологию XXX», «изучить лучшие практики YYY», «провести исследования перспективности нового направления ZZZ».
В такой постановке считаю подобные соцобязательства благом и для работодателя и для наемного работника. По сей день практикуем ежегодную аттестацию сотрудников, одним из результатов которой является рекомендации по личному развитию.
Крепостное право, вроде бы, отменили. Есть ли смысл тратить свою жизнь на мертворожденные проекты и работу с неадекватными работодателями?
ИМХО, это не совсем так.
50 лет назад сложные программные системы создавались без wiki, трекеров, календарей с напоминалками и даже (о ужас!) с проектной документацией на бумаге. Несмотря на постоянное появление все новых и новых инструментов поддержки разработки, согласно статистике, приведенной Демарко, средняя производительность в программостроении растет всего лишь на 3-5% в год.
Это происходит от того, что 80% времени программист работает головой и только 20% руками. А для повышения производительности работы мозга инструментов пока не придумали. Так что потенциал повышения эффективности работы программистов при помощи инструментов не превышает 20%.
ЗЫ. Не забудьте учесть затраты на развертывание, освоение и поддержку инструментария.
То, что вы описали, как я понял, похоже на путь к решению этой проблемы. Следующий шаг — осознать, что свойство != имя + значение, а является полноценным объектом, который проявляется во взаимодействии со свойствами других вещей.
Успехов.