Истерия, пораждает необдуманые действия, необдуманные действия пораждают проблемы.
Подход общения: «говорить только, то что нужно» — имеет место быть, но он странен по той причине, что мало кто лично может претендавать на знание того что действиетльно нужно. То что заказчика удобней всего рассматривать как ресурс — это очевидно. Но искренее общение с людьми (программистами и заказчиком), по моему опыту, куда эффективней чем попытки выбить «то что тебе нужно», не говоря «что тебе на самом деле нужно». Это резюме, дальше критика статьи.
«Основная сложность в управлении заказчиком… состоит в том, что заказчик ни в коем случае не должен знать, что он ресурс.»
— обязательно нужно объяснить, иначе он не будет нести ответственности за то, что делает, а вы будете его «пинать», что не эффективно. Попробуйте просто не употреблять столь жесткую терминологию: «ресурс» — это будет понятно заказчику, если он проффесиональный менеджер, иначе это может быть ему обидно (как Вы и заметили). Лучше всего объяснять что у него есть определенная роль в рамках проекта, которая включает в себя набор обязанностей и прав, просто раставьте точки над и сразу.
«Заказчики (да почти все) страдают дефицитом внимания. Не пишите им длинных писем.»
— на мой взгляд, идеальным способом общения является общение голосом, а лучше при личной встрече. Дальше уже ваша задача как менеджера, придумать способ фиксации принятых решений. Если общение отнимает много времени, снова объясните это заказчику и обязательно перечислете, что бы вы успели сделать за это время.
«Вы, разумеется, лучше заказчика знаете что ему нужно.» — к сожалению нет, заказчик может быть и не знает что ему нужно, но этот факт сам по себе не наделяет вас этим знанием. Истина, по опыту, выходит из обсуждений, долгих и многократных. А вот подсчет рисков и предложение альтернативных вариантов, действительно на вашей совести.
«Гениальное Письмо Заказчику… подводит заказчика к выбору правильного решения.» — если вы берете на себя отвественность за успешность бизнеса заказчика, то вы можете утверждать, что ваше решение правильное. В противном, случае я бы ограничелся предложением вариантов, описанием их плюсов/минусов и своим мнением, но не стал бы давить, как правило у заказчика есть, та ключевая информация, которой нет у меня и которой он вправе со мной не делиться.
«Поэтому если требования вам нужны край к пятнице, пишите Истеричное Письмо заказчику про понедельник.» — вы рискуете получить не полные/не обдуманные требования в худшем случае, в лудшем случае вы получите их после пятницы. Если сроки сдвигаются, по тому, что заказчик не предоставил что-то необходимое для их соблюдения — самое главное, убедиться, что он это понимает и все. Все. Истерия приводит к панике, паника ни к чему хорошему не приводит.
“Коллеги, у Вас проблемы” — я думаю, что менеджеров нанимают чтобы они решали чужие проблемы =) По мне лудшая формулировка будет: «Коллеги, у нас с Вами проблемы». А еще лучше, скажите что проблемы у Вас и дайте заказчику наконец самому спасти галактику, сказав только одно слово «да» или «нет». (Последние утверждение, весьма спорно конечно, — все зависит от человека с которым вы работаете).
«Заказчик не всегда отождествляет себя с проблемами своих проектов.» — главное чтобы они себя с командой проекта отождествляли, тогда и «у нас» будет всегда уместно.
«Не бойтесь ставить заказчику задачи.… в конце концов, в его же интересах.» — и это основное, что нужно объяснять, чтобы успешно мотивировать человека. Объясните, программисту, почему это ему нужно (только не рассказываете про зарплату) и он это сделает с радостью. С заказчиком все гораздо проще, он как раз обычно понимает зачем ему это нужно, только надо объяснить, почему необходимо чтобы именно он сделал эту работу (описал вот эти вот требования, ответил на вот эти вот вопросы… =))
«Заказчики ни черта не смыслят в технологиях.» — отнюдь, бывают весьма любопытные заказчики. А бывает нет. То что говорить на человечьем языке согласен (а на каком же еще), а вот на счет “Тебе лучше этого не знать." — весьма не разумно, может сложиться впечатление, что вы что то скрываете. Будте открыты, найдите такие слова, которые будут понятны, приведите примеры, постройте аналогии…
«Учите их. Делитесь знаниями.» — угу, именно!
Я дополню Ваш правильный, на мой взгял, финал к вашему не совсем правильному рассуждению, на мой взгляд. Будте открыты и искрени со своим заказчиком, помогайте ему и он поможет вам. И выбрасете Вы уже наконец своим методы кнута и пряника.
Я думаю, что все это спекуляции на старую тему кнута и пряника. Вы лишь облекли это в праздничную обертку кармы и виртуализировали (действительно, виртуальный кнут и пряник, что может быть лучше для менеджера, если бы они еще работали).
Хорошим показателем в Вашем эксперименте является то, что сотрудники не поднимают/опускают друг другу карму — и это не из-за отсутствия возможности объективно оценивать (иначе задумайтесь, зачем вам сотрудники которые не способны к объективной оценке) и даже не из-за желания «не навредить» коллегам, это из-за отсутствия мотивации к этой игре («Что лично для меня изменится, если поставлю Васе плюс или минус, если мы итак с ним нормально общаемся?»). А вот руководитель и его зам замативированы на использование этой системы, они стараются делать свою работу лучше и видят в этом способ делать ее лучше, поэтому и ставят.
Хороший момент это то, что помогли отстающему, но ему бы и так помогли, правда, правда (только Вы могли бы этого не заметить, а так заметили). Другие увидели, что человеку нужно помочь. Т. е. Вы хотели создать механизм мотивации, а создали механизм обмена информацией, что само по себе очень важно, но может быть достигнуто более тривиальными способами.
Мое мнение таково, что очевидные плюсы: налаживание коммуникаций внутри команды и появление возможности у менеджеров (Вас лично) оценивать ситуацию со стороны (коммуникация между менеджментом и командой); минусы: Вы изобретаете мотивационный велосипед.
Эксперимент интересный, если будете продолжать, хотелось бы читать про дальнейшие полученные результаты. Подумайте над тем, что я написал, хотя это всего лишь взгляд со стороны, основанный только на том, что Вы ретранслируете сюда.
Прошу прощения, что невольно наступил на Вашу мазоль.
Дело в привычке, Все слова написанные на английском языке имеют для меня смысл терминов (так например слово «кролик» в контексте обсуждения является метафорой, но не термином). Все термины англоязычного происхождения и заниматься трудностями перевода мне не хочется, поэтому я употребляю их как есть. К том же, так проще выделять термины из текста.
Еще раз приношу свои извинения.
P. S. По количеству взаимно наступленых мазолей мы квиты :)
CodeReview который здесь описан является предпосылкой к PairProgramming иначе, PairProgramming может быть поражден из хорошего и долго практикования CodeReview. Тем ни менее цели разные.
CodeReview ставит своей целью inspeciton: codestyle inspection, design inspection, algoritm inspection и т. д. Фактически это способ удержания качества самого кода, но не качества продукта. У CodeReview есть недостаток, который упоминался выше: это отвлечение вытягивание ревьювещего программиста из «потока», т. е. когда программист занят своей задачей и тут его отвлекают на ревью и ему срочно нужно выгружать, а потом загружать свою проблему из головы и обратно. Есть вариация OfflineCodeReview — реализуется с помощью специальных тулзов и нотификаций — это когда ревьюверу позволено делать ревью в удобное время в режиме оффлайн. Но у такого способа свой недостаток: если у вас достаточно короткие итерации, то вы будете терять ритм из-за длинных циклов попадания кода в основную ветвь разработки.
Логическим продолжением CodeReview является PairProgramming. Это такая мысль: а почему бы нам постоянно, в каждый момент не ревьювить код. В этом случае нет проблем с выгрузкой/загрузкой проблем в/из головы, потому как оба программиста делают это одновременно. Но PairProgramming ставит своей целью не inspection, а problem solving. И действительно это убийство сразу N зайцев: повышение эффективности — программисты постоянно поддерживают друг друга в потоке не давая отвлекаться на долго и давая друг другу передохнуть, постоянный inspection (review), и значительно улучшенный обмен знаниями и информацией в команде (хороший PairProgramming подразумевает смену пар). Однако часто можно услышать о не работоспособности PairProgramming, основной причиной к этому я считаю психологический фактор программистов и тут как раз важнейшую роль будет играть способность лидера команды к организации общего пространства мышления, но это уже совсем не в ключе этого поста…
1. Да, наверно я придираюсь :)
2. Потому что регрешен можно (и нужно) осуществлять не только юнит тестами, а юнит тесты служат не только для регрессии.
5. Scrum это agile планирование, он не поддерживает ни одной инженерной практики и не занимается вопросами кода в принципе.
Хорошую архитектуру очень важно использовать, но это ни уменьшает значения _интеграционного_ тестирования. Трое достаточно шустрых программиста способны разнести любую архитектуру очень быстро, ContinuesIntegration и UnitTest в том числе, позволяют следить, за тем чтобы этого не случилось. Также следить за этим помогают все практики направленные collaborations.
По поводу возражений, соглашусь, всегда нужно думать что собираешься тестировать.
Последнюю мысль не понял.
* ContinuesIntegration и UnitTests работают не только в отношении web applications и PHP — это о связи содержания с заголовком.
* Регрессионное тестирование и юнит тестирование — это разные вещи.
* UnitTest наиболее сильна, если ее применять в рамках TDD (Test Driven Development), иначе может иногда даже в пустую отнимать время. Как обычно, весьма сложно покрываемая юнит тестами область — пользовательские интерфейсы и даже упомянутый в статье selenium позволяет решить проблему только в небольшой части. Еще избавить код от непроверенных комитов позволяют такие практики как CodeReview и PairProgramming (вместе не применять :))
* о СontinuesIntegration имеет смысл говорить если у вас 3 и более разработчиков, одновременно комитящих код, в остальных случаях, если это не налаженная ранее система, то потеря времени.
* начиная всерьез внедрять эти практики, Вы уже начали думать о методологии :)
Подход общения: «говорить только, то что нужно» — имеет место быть, но он странен по той причине, что мало кто лично может претендавать на знание того что действиетльно нужно. То что заказчика удобней всего рассматривать как ресурс — это очевидно. Но искренее общение с людьми (программистами и заказчиком), по моему опыту, куда эффективней чем попытки выбить «то что тебе нужно», не говоря «что тебе на самом деле нужно». Это резюме, дальше критика статьи.
«Основная сложность в управлении заказчиком… состоит в том, что заказчик ни в коем случае не должен знать, что он ресурс.»
— обязательно нужно объяснить, иначе он не будет нести ответственности за то, что делает, а вы будете его «пинать», что не эффективно. Попробуйте просто не употреблять столь жесткую терминологию: «ресурс» — это будет понятно заказчику, если он проффесиональный менеджер, иначе это может быть ему обидно (как Вы и заметили). Лучше всего объяснять что у него есть определенная роль в рамках проекта, которая включает в себя набор обязанностей и прав, просто раставьте точки над и сразу.
«Заказчики (да почти все) страдают дефицитом внимания. Не пишите им длинных писем.»
— на мой взгляд, идеальным способом общения является общение голосом, а лучше при личной встрече. Дальше уже ваша задача как менеджера, придумать способ фиксации принятых решений. Если общение отнимает много времени, снова объясните это заказчику и обязательно перечислете, что бы вы успели сделать за это время.
«Вы, разумеется, лучше заказчика знаете что ему нужно.» — к сожалению нет, заказчик может быть и не знает что ему нужно, но этот факт сам по себе не наделяет вас этим знанием. Истина, по опыту, выходит из обсуждений, долгих и многократных. А вот подсчет рисков и предложение альтернативных вариантов, действительно на вашей совести.
«Гениальное Письмо Заказчику… подводит заказчика к выбору правильного решения.» — если вы берете на себя отвественность за успешность бизнеса заказчика, то вы можете утверждать, что ваше решение правильное. В противном, случае я бы ограничелся предложением вариантов, описанием их плюсов/минусов и своим мнением, но не стал бы давить, как правило у заказчика есть, та ключевая информация, которой нет у меня и которой он вправе со мной не делиться.
«Поэтому если требования вам нужны край к пятнице, пишите Истеричное Письмо заказчику про понедельник.» — вы рискуете получить не полные/не обдуманные требования в худшем случае, в лудшем случае вы получите их после пятницы. Если сроки сдвигаются, по тому, что заказчик не предоставил что-то необходимое для их соблюдения — самое главное, убедиться, что он это понимает и все. Все. Истерия приводит к панике, паника ни к чему хорошему не приводит.
“Коллеги, у Вас проблемы” — я думаю, что менеджеров нанимают чтобы они решали чужие проблемы =) По мне лудшая формулировка будет: «Коллеги, у нас с Вами проблемы». А еще лучше, скажите что проблемы у Вас и дайте заказчику наконец самому спасти галактику, сказав только одно слово «да» или «нет». (Последние утверждение, весьма спорно конечно, — все зависит от человека с которым вы работаете).
«Заказчик не всегда отождествляет себя с проблемами своих проектов.» — главное чтобы они себя с командой проекта отождествляли, тогда и «у нас» будет всегда уместно.
«Не бойтесь ставить заказчику задачи.… в конце концов, в его же интересах.» — и это основное, что нужно объяснять, чтобы успешно мотивировать человека. Объясните, программисту, почему это ему нужно (только не рассказываете про зарплату) и он это сделает с радостью. С заказчиком все гораздо проще, он как раз обычно понимает зачем ему это нужно, только надо объяснить, почему необходимо чтобы именно он сделал эту работу (описал вот эти вот требования, ответил на вот эти вот вопросы… =))
«Заказчики ни черта не смыслят в технологиях.» — отнюдь, бывают весьма любопытные заказчики. А бывает нет. То что говорить на человечьем языке согласен (а на каком же еще), а вот на счет “Тебе лучше этого не знать." — весьма не разумно, может сложиться впечатление, что вы что то скрываете. Будте открыты, найдите такие слова, которые будут понятны, приведите примеры, постройте аналогии…
«Учите их. Делитесь знаниями.» — угу, именно!
Я дополню Ваш правильный, на мой взгял, финал к вашему не совсем правильному рассуждению, на мой взгляд. Будте открыты и искрени со своим заказчиком, помогайте ему и он поможет вам. И выбрасете Вы уже наконец своим методы кнута и пряника.
Хорошим показателем в Вашем эксперименте является то, что сотрудники не поднимают/опускают друг другу карму — и это не из-за отсутствия возможности объективно оценивать (иначе задумайтесь, зачем вам сотрудники которые не способны к объективной оценке) и даже не из-за желания «не навредить» коллегам, это из-за отсутствия мотивации к этой игре («Что лично для меня изменится, если поставлю Васе плюс или минус, если мы итак с ним нормально общаемся?»). А вот руководитель и его зам замативированы на использование этой системы, они стараются делать свою работу лучше и видят в этом способ делать ее лучше, поэтому и ставят.
Хороший момент это то, что помогли отстающему, но ему бы и так помогли, правда, правда (только Вы могли бы этого не заметить, а так заметили). Другие увидели, что человеку нужно помочь. Т. е. Вы хотели создать механизм мотивации, а создали механизм обмена информацией, что само по себе очень важно, но может быть достигнуто более тривиальными способами.
Мое мнение таково, что очевидные плюсы: налаживание коммуникаций внутри команды и появление возможности у менеджеров (Вас лично) оценивать ситуацию со стороны (коммуникация между менеджментом и командой); минусы: Вы изобретаете мотивационный велосипед.
Эксперимент интересный, если будете продолжать, хотелось бы читать про дальнейшие полученные результаты. Подумайте над тем, что я написал, хотя это всего лишь взгляд со стороны, основанный только на том, что Вы ретранслируете сюда.
Дело в привычке, Все слова написанные на английском языке имеют для меня смысл терминов (так например слово «кролик» в контексте обсуждения является метафорой, но не термином). Все термины англоязычного происхождения и заниматься трудностями перевода мне не хочется, поэтому я употребляю их как есть. К том же, так проще выделять термины из текста.
Еще раз приношу свои извинения.
P. S. По количеству взаимно наступленых мазолей мы квиты :)
CodeReview ставит своей целью inspeciton: codestyle inspection, design inspection, algoritm inspection и т. д. Фактически это способ удержания качества самого кода, но не качества продукта. У CodeReview есть недостаток, который упоминался выше: это отвлечение вытягивание ревьювещего программиста из «потока», т. е. когда программист занят своей задачей и тут его отвлекают на ревью и ему срочно нужно выгружать, а потом загружать свою проблему из головы и обратно. Есть вариация OfflineCodeReview — реализуется с помощью специальных тулзов и нотификаций — это когда ревьюверу позволено делать ревью в удобное время в режиме оффлайн. Но у такого способа свой недостаток: если у вас достаточно короткие итерации, то вы будете терять ритм из-за длинных циклов попадания кода в основную ветвь разработки.
Логическим продолжением CodeReview является PairProgramming. Это такая мысль: а почему бы нам постоянно, в каждый момент не ревьювить код. В этом случае нет проблем с выгрузкой/загрузкой проблем в/из головы, потому как оба программиста делают это одновременно. Но PairProgramming ставит своей целью не inspection, а problem solving. И действительно это убийство сразу N зайцев: повышение эффективности — программисты постоянно поддерживают друг друга в потоке не давая отвлекаться на долго и давая друг другу передохнуть, постоянный inspection (review), и значительно улучшенный обмен знаниями и информацией в команде (хороший PairProgramming подразумевает смену пар). Однако часто можно услышать о не работоспособности PairProgramming, основной причиной к этому я считаю психологический фактор программистов и тут как раз важнейшую роль будет играть способность лидера команды к организации общего пространства мышления, но это уже совсем не в ключе этого поста…
2. Потому что регрешен можно (и нужно) осуществлять не только юнит тестами, а юнит тесты служат не только для регрессии.
5. Scrum это agile планирование, он не поддерживает ни одной инженерной практики и не занимается вопросами кода в принципе.
По поводу возражений, соглашусь, всегда нужно думать что собираешься тестировать.
Последнюю мысль не понял.
* Регрессионное тестирование и юнит тестирование — это разные вещи.
* UnitTest наиболее сильна, если ее применять в рамках TDD (Test Driven Development), иначе может иногда даже в пустую отнимать время. Как обычно, весьма сложно покрываемая юнит тестами область — пользовательские интерфейсы и даже упомянутый в статье selenium позволяет решить проблему только в небольшой части. Еще избавить код от непроверенных комитов позволяют такие практики как CodeReview и PairProgramming (вместе не применять :))
* о СontinuesIntegration имеет смысл говорить если у вас 3 и более разработчиков, одновременно комитящих код, в остальных случаях, если это не налаженная ранее система, то потеря времени.
* начиная всерьез внедрять эти практики, Вы уже начали думать о методологии :)