Сообщений в теме: 23

[Rost]

Вот мы вроде как, в очередной раз, обсудили тему мотивации персонала. У меня есть предложение обсудить вопросы мотивации руководства. Можно предложить развитие абстрактной компании. На каждом этапе необходимо работать с топ-менеджментом и, просто таки, добиваться улучшения отношения к тестированию в целом и тестировщикам в частности. Вот, на мой взгляд, типичные шаги в эволюции компании (одна из ветвей эволюции):
1. Тестирование только начинается в компании и руководство не желает тратиться на тестирование пока не увидит насколько это оправданно. Как заставить уверовать?
2. Тестирование есть. На каждом проекте есть свои тестеры. Проектов много, тестировщиков много, ими крутят кто как хочет. Надо организовать единый тестовый отдел. Как добиться и доказать?
3. Есть тестовый отдел, но уважаемые (я подчеркиваю именно уважаемые - те на ком держалась организация раньше и держится сейчас) проджект менеджеры не могут привыкнуть к тому что они уже не распоряжаются тестировщиками и, по старой памяти, занимаются планированием времени тетсировщиков даже после окончания проекта. Назовем это - этап становления отдела. Как избавиться от подобного вмешательства?
4. Все налажено, что дальше? Где те метрики которые могут показывать что тестирование в компании не остановилось на дотигнутом? Где результат для начальства?

Вот собственно хотелось бы по полочкам (т.е. по пунктикам) на каждый вопросик по ответу. Жду Вашего мнения коллеги.

[Rost]

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

Спасибо.

Я хочу задать вопрос. А как у Вас идет сообщение между командами? Ну например: высвобождается один тестировщик в очередном проекте. Где-то далеко на другом проекте ищут нового тестировщика. Логично перевести того кто освободился туда где нужен (считаем что проекты требуют одинаковых знаний от тестировщика). В таком случае как Вы описываете ПМы элементарно могут не знать нужды и ресурсы друг друга и будет набран еще один тестировщик. У Вас это кто-то координирует?

[_alexl_]

Соглашусь с drcoor

Как известно, многозадачность вредна применительно к людям. В организации, ориентированной на проекты, отдельный отдел тестирования - нонсенс. Тест-лид должен подчиняться ПМ-у поскольку заказчикам / клиентам нужен не контроль качества, а готовый продукт.

[Rost]

Соглашусь с drcoor

Как известно, многозадачность вредна применительно к людям. В организации, ориентированной на проекты, отдельный отдел тестирования - нонсенс. Тест-лид должен подчиняться ПМ-у поскольку заказчикам / клиентам нужен не контроль качества, а готовый продукт.

Скажите, а Вы всегда вели только один проект и не начинали другого пока не заканчивали предыдущий? Интересно, по Вашему получается что и R&D отделов тоже быть не должно. Так?
А как же развитие по "горизонтали"? Или оно только для ПМ, а тест менеджеров нет как класса?

[_alexl_]

Скажите, а Вы всегда вели только один проект и не начинали другого пока не заканчивали предыдущий? Интересно, по Вашему получается что и R&D отделов тоже быть не должно. Так? 
А как же развитие по "горизонтали"? Или оно только для ПМ, а тест менеджеров нет как класса? 

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

Вы будете смеяться, но я действительно считаю, что R&D отделов быть не должно, а должны быть R&D-проекты.

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

[Imbecile]

Соглашусь с drcoor

Как известно, многозадачность вредна применительно к людям. В организации, ориентированной на проекты, отдельный отдел тестирования - нонсенс. Тест-лид должен подчиняться ПМ-у поскольку заказчикам / клиентам нужен не контроль качества, а готовый продукт.

Смотря каким клиентам. Это во-первых.
А во-вторых, как уже говорилось, контроль качества - это не самоцель отдела тестирования, а один из способов производства (получения) качественного продукта. Наравне с такими способами, как производство пользовательской документации (я, к примеру, руковожу ещё и тех-писателями) и т.д.

[Rost]

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

Без обид - может Вы просто не готовы?
Скажите пожалуйста, вот Вы сейчас ПМ, кто у Вас начальник и что входит в его обязанности(next level manager)?

Вы будете смеяться, но я действительно считаю, что R&D отделов быть не должно, а должны быть R&D-проекты.

Значит каждый ПМ руководит своим проектом от начала переговоров и до получения денег? А кто будет продавать имя компании и искать новые проекты если все ПМы уже имеют свои проекты?
Что-то тут не так...

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

Нет. Горизонтальный рост как раз и подразумевает увеличение количества проектов у человека (с вытекающим увеличением подчиненных). Имеется ввиду что человек не растет карьерно (оставаясь на той же ступени иерархии), однако имеет возможность развивать свои знания и опыт за счет увеличения проектов\подчиненных и за счет большей ответственности. Ведь не могут же все быть СЕО.
Исходя из Ваших слов ПМ никогда не достигнет новой ступени потому что, во-первых ее не должно быть, а во-вторых у него всегда будет один проетк и его команды будут меняться незначительно отсюда у него не будет опыта руководить большим количеством людей и проектов.

Не могли бы Вы описать как Вы видите нормальную проектно-ориентированную компанию. Имеется ввиду структура этой компании(должности, иерархия, что происходит между проектами, т.е. один сдали что делать с командой).

[I_G]

Как-то первый вопрос незаслуженно обходится стороной.

1. Тестирование только начинается в компании и руководство не желает тратиться на тестирование пока не увидит насколько это оправданно. Как заставить уверовать?

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

[Rost]

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

Спасибо. А нельзя ли эти "общеизвестные факты" в студию пожалуйста. Те кто только начинает может и не знать.

[Rost]

Отвечу сразу всем на примере: у фирмы 2 крупных проекта и отдел краткосрочных проектов. Соответственно, 3 ПМ-а и 3 команды. Координирует их нач. департамента программирования - не такой уж и большой размах, чтоб он не справился.

Согласен размах не большой. А кто у Вас выполняет роль куратора тестировщиков?
Пример из моей практики, ко мне подошел большой начальник (выше чем начальник R&D отдела) и говорит, вот я все повышаю тестеровщикам зарплаты и никто мне не может сказать насколько обоснованно. И я с ним согласился. Пойдем снизу вверх, над тестером есть: 1. тим лид тестирования (с ним все понятно, он переживает за своих, сам деньги не платит и считает что поощрять надо постоянно и побольше, тогда у него в команде все будет хорошо); 2. ПМ (вообще не знает уровня тестировщика ввиду того что он не вникает в работу простых тестировщиков и, зачастую, просто не может определить прогресс тестировщика, на самом деле это не его дело); 3. Руководитель R&D отдела и выше (вообще в такие вещи не лезут впринципе).
Вот и получается, что нельзя сказать за что фирма платит, за выслугу лет? Получается, что один тестировщик просто таки разрывает всех и все (к статит фирма на нем еще может и экономит, потому что он один может делает двойную среднестатистическую норму по фирме), а другой не напрягается и получает в результате больше.
Как у Вас это решается?

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

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

[I_G]

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

Спасибо. А нельзя ли эти "общеизвестные факты" в студию пожалуйста. Те кто только начинает может и не знать.

Приводятся различные данные. Но, в среднем, картина довольно прозрачная, например:
1. В больших проектах каждая стадия разработки, которую переживает ошибка, увеличивает стоимость ее устранения в 10-50 раз. Исправление дефекта, допущенного во время дизайна системы и обнаруженного на стадии тестирования, может обойтись в сотни раз дороже, чем если бы он был обнаружен сразу. Источник: статья в RSDN
2. Вице-президент «Белл лэбс» по компьютерной технологии и системам военного назначения Е. Самнер считает, что на интервале от выработки требований на программы до сдачи программного продукта заказчику стоимость расходов на исправление ошибки возрастает в среднем в 80 раз. «Чем дольше ошибка остается в системе, тем дороже становится ее исправление»,— подчеркивает он.
3. Приводились следующие данные о средней стоимости исправления ошибки в зависимости от этапа цикла жизни программы, на котором соответствующая ошибка «всплывала» (по данным исследований фирм «TRW», «GTE Corp.» и «IBM»): на этапе составления спецификаций— 140 долл.; кодирования — 1000 долл.; комплексной отладки — 7000 долл.; сопровождения (у заказчика) — от 14000 до 140000 долл. на каждую ошибку.

[Rost]

Приводятся различные данные. Но, в среднем, картина довольно прозрачная, например:
1. В больших проектах каждая стадия разработки, которую переживает ошибка, увеличивает стоимость ее устранения в 10-50 раз. Исправление дефекта, допущенного во время дизайна системы и обнаруженного на стадии тестирования, может обойтись в сотни раз дороже, чем если бы он был обнаружен сразу. Источник: статья в RSDN
2. Вице-президент «Белл лэбс» по компьютерной технологии и системам военного назначения Е. Самнер считает, что на интервале от выработки требований на программы до сдачи программного продукта заказчику стоимость расходов на исправление ошибки возрастает в среднем в 80 раз. «Чем дольше ошибка остается в системе, тем дороже становится ее исправление»,— подчеркивает он.
3. Приводились следующие данные о средней стоимости исправления ошибки в зависимости от этапа цикла жизни программы, на котором соответствующая ошибка «всплывала» (по данным исследований фирм «TRW», «GTE Corp.» и «IBM»): на этапе составления спецификаций— 140 долл.; кодирования — 1000 долл.; комплексной отладки — 7000 долл.; сопровождения (у заказчика) — от 14000 до 140000 долл. на каждую ошибку.

Спасибо, от себя добавлю:
"По данным американского Национального института программного обеспечения и технологий (NIST), некачественное тестирование софта обходится США почти в 60 млрд. долларов ежегодно. При этом учитывалась только стоимость исправления ошибок - во сколько ошибки обходятся пользователям и какой урон наносят бизнесу, в NIST не знают. В USA Today писали о 100 миллиардах долларов в год, однако методика подсчетов неизвестна."

[_alexl_]

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

Без обид - может Вы просто не готовы?
Скажите пожалуйста, вот Вы сейчас ПМ, кто у Вас начальник и что входит в его обязанности(next level manager)?

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

Проект, который я сейчас веду, длится уже два года и требует высочайшего уровня понимания содержательной части. Да, если подходить чисто административно, то можно одновременно тянуть еще два таких же проекта. Но вы действительно считаете, что PM не должен понимать содержания?

Значит каждый ПМ руководит своим проектом от начала переговоров и до получения денег? А кто будет продавать имя компании и искать новые проекты если все ПМы уже имеют свои проекты?
Что-то тут не так... 

Процесс продажи должен вести не ПМ, это не его обязанность. ПМу нужно только участвовать и следить, чтобы в пылу переговоров клиенту не было обещано слишком много несбыточного. Это решает "кто будет продавать, если все ПМ'ы заняты".

Если все ПМы уже имеют проекты, то надо либо искать новых ПМов, либо приостанавливать продажи. Иначе компания рискует сильно пострадать от "несварения желудка", нахватавшись контрактов, которые не может должным спросом выполнить. ИМХО, повышенный спрос правильнее конвертировать в прибыль за счет повышения расценок, а не переводом всех лучших сотрудников на работу над несколькими проектами. Хотя бы для того, чтобы лучшие разработчики и ПМ не свалили в компанию, которая понимает, что многозадачность ведет к излишней суете и потере производительности.

Рекомендую почитать Джоэля Спольски, "О вреде многозадачности применительно к людям"
http://local.joelons...ительно_к_людям

[Rost]

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

Проект, который я сейчас веду, длится уже два года и требует высочайшего уровня понимания содержательной части. Да, если подходить чисто административно, то можно одновременно тянуть еще два таких же проекта. Но вы действительно считаете, что PM не должен понимать содержания?

ПМ может не знать (и зачастую не знает) предметную область (похоже Вы это имели ввиду под "содержанием") на уровне девелопера. Да это и не нужно. Мы можем много дискутировать, но похоже все крутится вокруг подхода ПМа к работе. Вы, как я посмотрю, пропагандиуете involved метод. Т.е. стараетесь во всем учавствовать и быть в курсе всего. Этот метод вполне рабочий, вот только требует от менеджера недюжей работоспособности.
Я лично предпочитаю такие методы оставлять на самый крайний случай. Кстати Ваш президент, по сути, ведет все проекты компании. Я имею ввиду то же самое только на уровень ниже. Если посмотреть, то разницы никакой.

Процесс продажи должен вести не ПМ, это не его обязанность. ПМу нужно только участвовать и следить, чтобы в пылу переговоров клиенту не было обещано слишком много несбыточного. Это решает  "кто будет продавать, если все ПМ'ы заняты".

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

Если все ПМы уже имеют проекты, то надо либо искать новых ПМов, либо приостанавливать продажи. Иначе компания рискует сильно пострадать от "несварения желудка", нахватавшись контрактов, которые не может должным  спросом выполнить. ИМХО, повышенный спрос правильнее конвертировать в прибыль за счет повышения расценок, а не переводом всех лучших сотрудников на работу над несколькими проектами. Хотя бы для того, чтобы лучшие разработчики и ПМ не свалили в компанию, которая понимает, что многозадачность ведет к излишней суете и потере производительности.

Рекомендую почитать Джоэля Спольски, "О вреде многозадачности применительно к людям"
http://local.joelons...ительно_к_людям

Ух. Круто Вы...
Ообенно про повышение расценок... Как-то даже про конкуренцию забывается...
Кстати, как на Ваш взгляд получаются такие люди как Ваш президент? Он ведь может вести все Ваши проекты. И от этого никто никуда не бежит...

Да, кстати про разработчиков и тестировщиков речь не идет. Разговор только по теме. Менеджмент.

[_alexl_]

Softquacoman, у меня несколько вопросов к вам:

1. Ваша компания занимается корпоративным софтом, коробочными продуктами или вообще чем-то третьим?

2. Разработчики делят время между проектами таким же образом как ПМ'ы?

3. Есть ли в проекте человек, который отвечает за содержательную сторону? Если есть, какие у него полномочия?

[Rost]

Softquacoman, у меня несколько вопросов к вам:

Всегда рад услышать различные точки зрения.

1. Ваша компания занимается корпоративным софтом, коробочными продуктами или вообще чем-то третьим?

В общем есть и коробочные продукты, но наше подразделение занимается проектами на заказ. Вашими словами чем-то третьим.

2. Разработчики делят время между проектами таким же образом как ПМ'ы?

Ну что жы Вы так настойчивы. Я еще раз повторю
"Да, кстати про разработчиков и тестировщиков речь не идет. Разговор только по теме. Менеджмент."

3. Есть ли в проекте человек, который отвечает за содержательную сторону? Если есть, какие у него полномочия?

Что бы правильно ответить на Ваш вопрос сперва надо определиться с терминологией. Что такое "содержательная сторона"? Имеется ввиду функционал?

[_alexl_]

2. Разработчики делят время между проектами таким же образом как ПМ'ы?

Ну что жы Вы так настойчивы. Я еще раз повторю
"Да, кстати про разработчиков и тестировщиков речь не идет. Разговор только по теме. Менеджмент."

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

Если все сильные специалисты в вашей компании параллельно ведут несколько проектов, то они неэффективно тратят свое время. Это серьезная проблема. Соответственно, можно подумать о том, как повысить эффективность труда основных участников проектов, а не менеджеров - это должно принести бОльшую отдачу.

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

[Rost]

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

Как-то выглядит как будто работа основных участников влияет на менеджмент, а не на оборот.

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

Именно про менеджмент и идет речь (все таки тема "Мотивация руководства").
Вобщем-то особо интересен ответ на последний вопрос (см. самый первый пост), но и на остальных этапах интересно кто как наладил работу.