Испорченный телефон не нужен конечно. Его задача не общаться, а сводить к общению.Ставить приоритеты, следить за сроками. Можно даже переименовать в координатора проекта. Работы у него хватает и работу эту не выкинуть, когда организация большая. Да и в небольшой организации тоже, где люди не умеют самостоятельно держать сроки и следовать приоритетам. (сейчас речь об идеальном ПМе)
Можно привести контр пример в виде Valve, но чего то их результаты удручают в плане доступности и качества сервиса. Других компаний без управленцев я не ведаю.
1. Не получится ли, что исключая звено тестировщиков, вы погружаете разработчиков в большую детализацию работы и тем самым повышаете зависимость от каждого конкретного человека (Bus factor)?
2. Насколько тяжело дается отработка кейсов человеку, который делает систему? Нет ли замыливания глаз?
3. Во время работы тестировщиков, разрабы обычно берутся за реализацию других задач. Получается некое распараллеливание. В вашем случае разработчик делает все сам, плюс ему больше придется общаться с пользователями и аналитиками. Что со временем? Не придется ли в итоге нанимать дополнительного разработчика?
Кстати о заработке. Не такая уж и редкость встретить функциональщика, который получает побольше многих разработчиков. Естественно это не аутсорсинг и не студенты.
Не выйдет.
Мышление складывается из того, чем приходится заниматься и с кем приходится общаться, а интересы и задачи у всех разные. Невозможно быть всевидящим и всеобъемлющим. Просто времени не хватит. Хорошо уже, когда люди находят общий язык. Это данность, которую надо учитывать.
Да я не спорю. Лишь ответил на вопрос.
По сему не могу успокоиться и еще раз нет) Задача ПМа — отправить лебедя, рака и щуку в одну сторону (ну хотя бы так чтоб вектора усилий не давали 0). Для осуществления проекта нужна толпа народу (с чего наш диалог и пошел), которые нередко и в глаза друг друга не видели. Кто-то должен их координировать и направлять.
Опять же нет. Частично исходя из различных взглядов у каждого. Разработчик даже с семью пядями будет видеть только проблемы разработки. Аналитик будет видеть только проблемы бизнеса. Функциональный тестировщик и автоматизатор смотрят уже со стороны потребителя продукта. Области конечно перекрываются, но крайне слабо. Все 3 группы (можно обособленно поставить еще инженеров по производительности и тех кто связан с планированием мощностей, но они отдельная песня) говорят на разных языках и плохо понимают друг друга в виду различных контекстов «обитания». Вместе они могут составить некое необходимое для разработки целое.
Оставить только две группы нельзя. Потому что тяжело видеть одному человеку угол в 180 градусов, не вращая головой.
Нет. При разработке (особенно архитектуры) как правило много вариантов развития, и выбор оптимального редко очевиден. Бизнес требования довольно часто меняются, порой значительно для системы и без права на корректировку архитектуры. Нельзя сделать идеальный продукт раз и на всегда. Очень часто одним из ключевых критериев создания является скорость, что негативно влияет на качество. Да и задач на программистах не по одной и держать детали реализаций всего и вся в голове невозможно. К аналитикам это скорей всего относится в равной степени.
Это самое очевидное, но есть еще к примеру различные ракурсы у различных участников проекта, что тоже вносит влияние.
Раньше прощали многое из огрехов. Сейчас более требовательные стали. Можно провести аналогию с развитием кино. Правда вся эта очевидность рушится о всякие dwarf fortress, meat team и т.д. Был на хабре перевод про некий поток, в который погружаешься во время игры. Возможно это ближе к истине.
Такого много пишут. Пробуют, не понравилось, пост ненависти. Причем конкретные претензии видел только один раз, но все равно свелось к вкусовщине. Уже поднадоело.
Клипсу не тыркал, но плагин в идее иногда бесит. Форматирование кода страдает, автозавершения конструций (например при объявлении функции) нету. Вдобавок не нашел, как в созданном проекте изменить компиллятор скалы.
Можно привести контр пример в виде Valve, но чего то их результаты удручают в плане доступности и качества сервиса. Других компаний без управленцев я не ведаю.
2. Насколько тяжело дается отработка кейсов человеку, который делает систему? Нет ли замыливания глаз?
3. Во время работы тестировщиков, разрабы обычно берутся за реализацию других задач. Получается некое распараллеливание. В вашем случае разработчик делает все сам, плюс ему больше придется общаться с пользователями и аналитиками. Что со временем? Не придется ли в итоге нанимать дополнительного разработчика?
Мышление складывается из того, чем приходится заниматься и с кем приходится общаться, а интересы и задачи у всех разные. Невозможно быть всевидящим и всеобъемлющим. Просто времени не хватит. Хорошо уже, когда люди находят общий язык. Это данность, которую надо учитывать.
По сему не могу успокоиться и еще раз нет) Задача ПМа — отправить лебедя, рака и щуку в одну сторону (ну хотя бы так чтоб вектора усилий не давали 0). Для осуществления проекта нужна толпа народу (с чего наш диалог и пошел), которые нередко и в глаза друг друга не видели. Кто-то должен их координировать и направлять.
Оставить только две группы нельзя. Потому что тяжело видеть одному человеку угол в 180 градусов, не вращая головой.
Это самое очевидное, но есть еще к примеру различные ракурсы у различных участников проекта, что тоже вносит влияние.