С моей точки зрения что-то подобное и языками программирования — когда появились ЯВУ возникла возможность быть постановщиком сам себе — в один мозг влезает формальный язык и предметная область
См в исходном тексте:
«Вместо того, чтобы сказать «Это невозможно!» необходимо просто взять паузу, подумать, остыть, а затем сесть со своим тимлидом или руководителем и проговорить проблему. „
Таким образом никто не говорит, что разработчик бессловесная тварь, которая не может вообще ничего сказать. Но последнее слово за менеджером, так как он представляет интересы клиента.
>>>Но есть также ваяние бизнес фич/отчетов/поддержка бухгалтерии и т.д., где места для творчества почти нет.
Там есть некоторое место для творчества, если человек думает о том как он работает, а не тупо переводит с человеческого языка на машинный. Конечно там творчества маленькое, не мирового масштаба, но оно есть. Представьте себе некоторый спектр: пусть абсолютное отсутствие творчества, это рабочий на конвеере завинчивающий гайку, причем, не думая о работе вообще, а чистое творчество — ученый придумывающий единую теорию всего 100% времени. Мне кажется любой программист где-то между этими точками, только от рода его работы и подхода к ней зависит, где именно.
В-общем, примерно такая же аналогия уже много лет используется в рассуждениях о ПО, например у Мартина нашего Фаулера — попробуйте почитать там.
А вот тут повеселее
Software development is only like bridge building if you're building a bridge on the planet Jupiter, out of newly invented materials, using construction equipment that didn't exist five years ago.
В программировании то же самое, только готовое блюдо по рецепту делает робот. Иногда его называют компилятор. Если привлекают человека, значит блюдо по существующему рецепту не подходит иначе бы его просто скопировали
Если разработчик не исполняет обязанности менеджера, не его дело выбирать, какие возможности нужны пользователю, а какие нет, так как он не видит картины в целом и value с точки зрения бизнеса. У него совещательный голос. Мне кажется во всех методология так. У него своя область ответственности относящаяся к реализации хотелок, а не их приоритета. Иначе он должен предоставлять экономическое обоснование
Канбан — просто способ визуализации общий принцип — не берем новое, пока кто-то не освободится (вернее пока количество задач в работе не становится меньше чем экспериментально подобранное число work in progress) есть отдельная полоса пропускания для срочных задач — expedite lane, но туда тоже нельзя помещать больше определённого количества. Отслеживаем среднее время прохождение через процесс и очереди на каждом этапе.
Вы же сами писали, что разработчики говорят «это невозможно» чтобы пропустить премиальную задачу — то есть дестимулирует решать другие задачи.
Если всем плевать на прозрачные планы можно начать работать спокойно в стиле канбана — не берётся за новое пока не сделаем текущее + expedite lane с фиксированным wip на срочные таски
Имхо премия только дестимулирует в вашем случае и менеджер не выполняет часть своей работы по донесению до заказчиков вреда от переключений работы вы ему такое говорили? (только переформулируя позитивно)
я совершенно согласен с такой постановкой вопроса. Но во-первых, я говорю не о взятии полностью ответственности за чужой участок работы, а о посильный помощи — человек написал непонятное или противоречивые ТЗ — обрати внимание, человек написал избыточно подробно — подскажи как сэкономить время. То есть области ответственности долины иметь перекрытие — так как мы имеем дело с людьми, а не с кирпичом то если перекрытий не будет — будут пустые пространства и качество пострадает. В случае с багтрекингом рассматриваем задачу когда бага уде пришла к тебе с просьбой исследовать возможные причины и дать рекомендации по воспроизведению, например. Или можешь сам предложить, но дело менеджера — решить надо так помогать QA или нет. Ты не отнимаешь опыт у других, а делиться им — от взаимодействия с разработчиком постановщик лучше поймет как составить ТЗ более логично. Тестеры будут знать, что можно не только тупо перебирать варианты, но и попросить разработчика добавить диагностику или научатся анализировать крешдампы.
Все работают на общее благо как могут, но дело каждого знать — где он принимает решение, а где он моет использовать возможность совещательного голоса.
Еще по поводу разделения труда — вот такой пример — почему нету специального человека для завязывания шнурков — он будет все делать быстрее и качественнее?
Интересно, что в каждом пункте вы пытаетесь доказать, что разработчик не виноват, а я пытаюсь показать, как должен действовать разработчик для выпуска более качественного продукта.
1. Если бага критическая и она воспроизводится только у клиента, то разработчик может помочь со своей стороны: добавить диагностику в код, посмотреть по коду вероятные причины и попробовать воспроизвести и т.д,
2 Опять поиск виноватого.Хороший разработчик может помочь улучшить ТЗ. Опять-таки, если ты бездумно вытачиваешь болванки по ТЗ не твое дело обсуждать интеллектуальные способности пользователя — для этого есть другие специальные люди.
3. Согласен, все несут ответственность. Не ищем виноватого, а делаем что можем, чтобы было лучше
5. Дело всех обеспечивать процесс со своей колокольни Если разработчик предпримет небольшие усилия, чтобы быть понятным окружающими, продукт будет лучшего качества, а разработчик более щедро оплачен.
7. Должен или не должен — зависит от конкретной ситуации, но это неинтересно. Интересно, как разработчик может стать лучше — общаться с коллегами приходится всегда и быть понятным коллегами разных уровней — весьма полезно.
4. Ну вопросы я практикую, когда уверен менее чем на 90% что косяк. Иначе можно просто высказывать в мягкой некатегоричной форме
«Вместо того, чтобы сказать «Это невозможно!» необходимо просто взять паузу, подумать, остыть, а затем сесть со своим тимлидом или руководителем и проговорить проблему. „
Таким образом никто не говорит, что разработчик бессловесная тварь, которая не может вообще ничего сказать. Но последнее слово за менеджером, так как он представляет интересы клиента.
Там есть некоторое место для творчества, если человек думает о том как он работает, а не тупо переводит с человеческого языка на машинный. Конечно там творчества маленькое, не мирового масштаба, но оно есть. Представьте себе некоторый спектр: пусть абсолютное отсутствие творчества, это рабочий на конвеере завинчивающий гайку, причем, не думая о работе вообще, а чистое творчество — ученый придумывающий единую теорию всего 100% времени. Мне кажется любой программист где-то между этими точками, только от рода его работы и подхода к ней зависит, где именно.
2. www.codinghorror.com/blog/2005/05/bridges-software-engineering-and-god.html
А вот тут повеселее
Software development is only like bridge building if you're building a bridge on the planet Jupiter, out of newly invented materials, using construction equipment that didn't exist five years ago.
Если всем плевать на прозрачные планы можно начать работать спокойно в стиле канбана — не берётся за новое пока не сделаем текущее + expedite lane с фиксированным wip на срочные таски
Все работают на общее благо как могут, но дело каждого знать — где он принимает решение, а где он моет использовать возможность совещательного голоса.
Еще по поводу разделения труда — вот такой пример — почему нету специального человека для завязывания шнурков — он будет все делать быстрее и качественнее?
Вы читали книжки от 37signals?
1. Если бага критическая и она воспроизводится только у клиента, то разработчик может помочь со своей стороны: добавить диагностику в код, посмотреть по коду вероятные причины и попробовать воспроизвести и т.д,
2 Опять поиск виноватого.Хороший разработчик может помочь улучшить ТЗ. Опять-таки, если ты бездумно вытачиваешь болванки по ТЗ не твое дело обсуждать интеллектуальные способности пользователя — для этого есть другие специальные люди.
3. Согласен, все несут ответственность. Не ищем виноватого, а делаем что можем, чтобы было лучше
5. Дело всех обеспечивать процесс со своей колокольни Если разработчик предпримет небольшие усилия, чтобы быть понятным окружающими, продукт будет лучшего качества, а разработчик более щедро оплачен.
7. Должен или не должен — зависит от конкретной ситуации, но это неинтересно. Интересно, как разработчик может стать лучше — общаться с коллегами приходится всегда и быть понятным коллегами разных уровней — весьма полезно.
4. Ну вопросы я практикую, когда уверен менее чем на 90% что косяк. Иначе можно просто высказывать в мягкой некатегоричной форме