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

[SALar]

С "бездельничающими" тестировщиками есть нежелательный побочный эффект. Если задач мало и тестировщик понимает, что успеет выполнить  все и еще время останется, он, видимо из-за своих человеческих слабостей , начинает работать медленнее. Мало-помалу он привыкает к новому расслабленному ритму и нормальная нагрузка начинает восприниматься как "перегруз" :) 

А пожарных, которые не тушат постоянно пожары, нужно уволить... Как вариант, в отсутствии пожаров устраивать поджоги. Шобы не расслаблялись и не теряли революционной бдительности.

 

Шикарный метод. Почти такой же шикарный, как "подратировать команду" у Дорофеева.

 

 Так что, наверное, стоит воспринимать задержку при ручном тестировании как неизбежное зло. 

Нет. Проблема в другом. Ответ дал много лет назад Ашманов: "Бессмысленно муштровать исполнителей, нужно муштровать менеджеров."

 

Деминг и Голдратт говорили ровно о том же.

 

Выход - делать автотесты.

 

Офигенный вывод. Прям как у свидетелей иеговы. "Вы заболели грипом, значит надо верить в автотесты".

Л - Логика!

[SALar]

Да, если вы не согласны, предлагаю сыграть в "сбалансированную производственную цепочку". Как говорится: "Или делай ставку, или не предлагай."

 

PS. Естественно, играть будем на мелкие деньги. Чтобы не было интереса, подарим их кому нибудь. Да хоть кому то из стажеров билет на тренинг оплатим.

[SALar]

 

Правило 17. Бессмысленно муштровать исполнителей, нужно муштровать менеджеров.

Это правило легко доказать следующим рассуждением:

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

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

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

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

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

Таким образом, "лечить" исполнителей либо через голову среднего менеджера, либо при его поддержке (что еще более отвратительно) в большинстве случаев теоретически неправильно и практически вредно.

[leftCh]

> А пожарных, которые не тушат постоянно пожары, нужно уволить...

> Ответ дал много лет назад Ашманов: "Бессмысленно муштровать исполнителей, нужно муштровать менеджеров."

Я говорила кого-то муштрировать или увольнять? Нет.

 

> Да, если вы не согласны, предлагаю сыграть в "сбалансированную производственную цепочку".

Не то чтобы не согласна. Просто поделилась наблюдением. А у вас был другой опыт? Когда тестировщики при загрузе 75% сию же минуту начинали работать над упавшими в очередь задачами?

 

> Офигенный вывод. Прям как у свидетелей иеговы. "Вы заболели грипом, значит надо верить в автотесты".

> Л - Логика!

 

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

[SALar]

> Да, если вы не согласны, предлагаю сыграть в "сбалансированную производственную цепочку".

Не то чтобы не согласна. Просто поделилась наблюдением. А у вас был другой опыт? Когда тестировщики при загрузе 75% сию же минуту начинали работать над упавшими в очередь задачами?

У меня этого опыта выше крыши. Видел я и такие цепочки

Первая линия приняла задачу -> аналитик написал ТЗ отдал юристу на посмотреть -> юрист скорректировал -> аналитик дописал ТЗ ->сисадмины развернули среду передали задачу дальше -> дежурный программист не справился, передал свободному старшему -> программист сделал отдал тестировщикам -> тестировщик завернул с ошибками -> программит исправил -> тестировщик принял -> дизайнер изменил интеррфейс -> [ здесь еще несколько телодвижений ] -> сисадмин выкатил хотфикс в прод

 

Все про все сделано в течении одного рабочего дня.

Это называется правильная организация труда.

 

> Офигенный вывод. Прям как у свидетелей иеговы. "Вы заболели грипом, значит надо верить в автотесты".

> Л - Логика!

 

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

Ахинею можно услышать от кого угодно.