Дельное замечание, спасибо! Особенно за книгу, которую не могу теперь нигде найти в продаже :)
Считаю свой метод относительно свободным от данного заболевания, так как менеджер при опровержении оценки разработчика обязан объяснить то, как он предлагает сделать это быстрее. И это не маловажный пункт, который я, к сожалению, не отметил жирным шрифтом.
Я недавно закончил ремонт в квартире, и не раз с работниками возникал вопрос об оплате и сроках. Когда исполнители заявляют цену они обосновывают это некой сложностью работы. Если попросить рассказать как он собирается выполнять эту работу, очень часто для самого исполнителя она начинает выглядеть не такой сложной. А иногда выясняется что исполнитель банально не компетентен и реально не знает как он будет ее выполнять.
Очень важно чтобы исполнитель знал в какой последовательности что он будет делать. Чем четче он представляет себе последовательность, тем быстрее и качественнее он сможет эту работу выполнить.
У меня даже тест есть такой для отбора претендентов на должность монтажников — обьяснить как они будут вешать ящик.
Варианты ответов:
Вася:
— Ну, это, возьму и повешу.
— А что вы сделаете сначала?
— Ну сначала я это, прикручу ящик.
— А отверстия для анкеров когда будете делать?
— А, да, сначала отверстия просверлю.
и т.д.
Петя:
— Сначала я выберу место куда его повесить, так чтобы сверху не капало и не далеко электричества. Затем приставлю его к стене и отмерю отверстия под болты. Затем возьму перфоратор со сверлом на 10 мм, просверлю отверстия и вставлю анкера. Затем одену ящик и прикручу гайки.
Как вы думаете кто выполнит задачу четко и в срок и кого возьмут на работу?
Мотивация тут не причем. Главное чтобы человек мог объяснить как он это будет делать. Когда он будет знать как он сделает, он будет знать и точный срок.
Чаще же всего сроки называют просто от балды, на глаз определяя сложность/легкость.
В Советском Союзе с системами мотивации и управления было все в порядке.
До сих пор встречаю среди современных консультантов по управлению «новоявленные методики», описанные еще в 70-х года отечественными социологами. Слишком многое мы выкинули, как «само собой разумеется неправильное», только потому что это применялось в СССР, даже не углубляясь в детали.
Смотря какая задача. Я предпочитаю долго обсуждать и быстро делать.
А если разработчик всегда без обсуждения и планов точно выдает срок с которым ты согласен и в этот срок укладывается — то им с таким разработчиком и методик управления никаких не нужно.
Дело в том, что цель статьи ознакомить с методикой и только. Хотя приведенные выше тесты в рамках cucumber-а рабочие — проверено. Что касается нюансов реализации поступков, то они описаны так умышленно, для упрощения понимания, опять таки работы самого cucumber-а.
Насчет «шагов» и «поступков» вы также правы. Но мне больше нравится слово «поступки», так как «шаги» часто употребляется с иными контекстом и может ввести в заблуждение. Слово шаги также подразумевает некоторую этапность, которая в случае с (step definition) отсутствует.
Насчет environment — как уже говорил, приведенные настройки кукумбера работают и так, остальное уже выходит за рамки данной статьи.
Согласен, нужно освятить этот вопрос более подробно, но для этого необходимо также ввести публику и shoulda, и в webrat, также желательно ознакомить factory_girl и mocha, иначе не будет понятно где мы говорим о BDD и огурце, а где применяем другие инструменты.
Предлагаю разделиться и написать нам статьи по этим темам. А в конце заключительную статью, в которой полностью рассмотрим разработку реального приложения с помощью этих инструментов.
С русским есть только одна проблема — интеграция со свойствами других проектов (плагинов и модулей) коих в своем великое множество — получается каша. Ну и еще по умолчанию некоторыми пакетами многие поступки уже прописываются на английском.
Ух-ты, я тоже люблю! Очень интересно проводить собеседование работодателей — многому учишься сам, когда видишь как все это выглядит со стороны. Пора писать обратную статью — Как правильно выбрать работодателя.
Особенно понравилось: «Сайт как поток информации, которую нужно донести до посетителей»
Будучи в своей жизни и исполнителем, и заказчиком заметил:
Заказчиков, понимающих что они хотят и доверяющих разработчику, в процентом соотношении столько-же, сколько разработчиков, которые знают «как» и которым можно доверять. И тех и других примерно 20% от общей массы.
Для примера возьмем сервис Lovely Charts, который, подобно своим конкурентам, позволяет строить схемы, карты сайтов и диаграммы онлайн. Подобных сервисов бесконечное множество..
А можно подробнее про бесчисленное множество? Давно ищу хороший бесплатный он-лайн сервис для разработки схем, UML.
Тоже считаю важным в дальнейшем поддерживать связь нашедших друг друга через сайт. Не всегда хочется светить свои координаты и тп. Кроме того появляется хорошая возможность добавить рейтингование по уже выполненной помощи.
Говоря точнее, это удобный способ «тыкать пальцем» в дыры в бизнес-процессе, которые нижестоящий руководитель должен был закрывать.
Непонятно как автор из стремления работать на результат перешел закрыванием дыр в бизнес-процессы и тыканьем пальцем. Если дыры в бизнес-процесса мешают достижению намеченного результата их закрывают, если не мешают — не обращают внимания.
А пальцем тыкать можно вообще на что угодно.
Непонятно какое отношение к работе на результат имеет стресс? ЧТо в других работах его нет?
Автор явно путает результат как «цель» с чем-то другим. Чувствуется мешанина.
Я думаю, что ее корень кроется где-то в словах «руководитель должен». Кто это ему, бедняге, уже определил его должность? Разные руководители — различные обязанности и цели и, соответственно, результат. Что дожен делать руководитель и зачем нужно спрашивать у того, кто его «руководителя» поставил. А если он самопоставленный — то его личные цели в области руководства. Может быть у него цель совершить прорыв в области экспериментальной физики? Тогда ему не бизнес процессы налаживать надо, а искать талантливых ученых и деньги на эксперименты.
Очевидно автор написал статью под действием личных отрицательных эмоций от руководителей перечитавших книжек про результат. Поэтому указанные ошибки прощаются.
Считаю свой метод относительно свободным от данного заболевания, так как менеджер при опровержении оценки разработчика обязан объяснить то, как он предлагает сделать это быстрее. И это не маловажный пункт, который я, к сожалению, не отметил жирным шрифтом.
Я недавно закончил ремонт в квартире, и не раз с работниками возникал вопрос об оплате и сроках. Когда исполнители заявляют цену они обосновывают это некой сложностью работы. Если попросить рассказать как он собирается выполнять эту работу, очень часто для самого исполнителя она начинает выглядеть не такой сложной. А иногда выясняется что исполнитель банально не компетентен и реально не знает как он будет ее выполнять.
Очень важно чтобы исполнитель знал в какой последовательности что он будет делать. Чем четче он представляет себе последовательность, тем быстрее и качественнее он сможет эту работу выполнить.
У меня даже тест есть такой для отбора претендентов на должность монтажников — обьяснить как они будут вешать ящик.
Варианты ответов:
Вася:
— Ну, это, возьму и повешу.
— А что вы сделаете сначала?
— Ну сначала я это, прикручу ящик.
— А отверстия для анкеров когда будете делать?
— А, да, сначала отверстия просверлю.
и т.д.
Петя:
— Сначала я выберу место куда его повесить, так чтобы сверху не капало и не далеко электричества. Затем приставлю его к стене и отмерю отверстия под болты. Затем возьму перфоратор со сверлом на 10 мм, просверлю отверстия и вставлю анкера. Затем одену ящик и прикручу гайки.
Как вы думаете кто выполнит задачу четко и в срок и кого возьмут на работу?
А заказывать разработчику задачу, которую он не знает как решить, это уже венчур :)
Чаще же всего сроки называют просто от балды, на глаз определяя сложность/легкость.
До сих пор встречаю среди современных консультантов по управлению «новоявленные методики», описанные еще в 70-х года отечественными социологами. Слишком многое мы выкинули, как «само собой разумеется неправильное», только потому что это применялось в СССР, даже не углубляясь в детали.
А если разработчик всегда без обсуждения и планов точно выдает срок с которым ты согласен и в этот срок укладывается — то им с таким разработчиком и методик управления никаких не нужно.
Дело в том, что цель статьи ознакомить с методикой и только. Хотя приведенные выше тесты в рамках cucumber-а рабочие — проверено. Что касается нюансов реализации поступков, то они описаны так умышленно, для упрощения понимания, опять таки работы самого cucumber-а.
Насчет «шагов» и «поступков» вы также правы. Но мне больше нравится слово «поступки», так как «шаги» часто употребляется с иными контекстом и может ввести в заблуждение. Слово шаги также подразумевает некоторую этапность, которая в случае с (step definition) отсутствует.
Насчет environment — как уже говорил, приведенные настройки кукумбера работают и так, остальное уже выходит за рамки данной статьи.
Согласен, нужно освятить этот вопрос более подробно, но для этого необходимо также ввести публику и shoulda, и в webrat, также желательно ознакомить factory_girl и mocha, иначе не будет понятно где мы говорим о BDD и огурце, а где применяем другие инструменты.
Предлагаю разделиться и написать нам статьи по этим темам. А в конце заключительную статью, в которой полностью рассмотрим разработку реального приложения с помощью этих инструментов.
Что выбираете?
С русским есть только одна проблема — интеграция со свойствами других проектов (плагинов и модулей) коих в своем великое множество — получается каша. Ну и еще по умолчанию некоторыми пакетами многие поступки уже прописываются на английском.
Особенно понравилось: «Сайт как поток информации, которую нужно донести до посетителей»
Будучи в своей жизни и исполнителем, и заказчиком заметил:
Заказчиков, понимающих что они хотят и доверяющих разработчику, в процентом соотношении столько-же, сколько разработчиков, которые знают «как» и которым можно доверять. И тех и других примерно 20% от общей массы.
Вообще многим вебдизайнерам надо посоветовать изучать типографику и особенно вчитываться в Рудера.
А можно подробнее про бесчисленное множество? Давно ищу хороший бесплатный он-лайн сервис для разработки схем, UML.
Непонятно как автор из стремления работать на результат перешел закрыванием дыр в бизнес-процессы и тыканьем пальцем. Если дыры в бизнес-процесса мешают достижению намеченного результата их закрывают, если не мешают — не обращают внимания.
А пальцем тыкать можно вообще на что угодно.
Непонятно какое отношение к работе на результат имеет стресс? ЧТо в других работах его нет?
Автор явно путает результат как «цель» с чем-то другим. Чувствуется мешанина.
Я думаю, что ее корень кроется где-то в словах «руководитель должен». Кто это ему, бедняге, уже определил его должность? Разные руководители — различные обязанности и цели и, соответственно, результат. Что дожен делать руководитель и зачем нужно спрашивать у того, кто его «руководителя» поставил. А если он самопоставленный — то его личные цели в области руководства. Может быть у него цель совершить прорыв в области экспериментальной физики? Тогда ему не бизнес процессы налаживать надо, а искать талантливых ученых и деньги на эксперименты.
Очевидно автор написал статью под действием личных отрицательных эмоций от руководителей перечитавших книжек про результат. Поэтому указанные ошибки прощаются.
Пишите еще :)