Здравствуйте, Sinclair, Вы писали:

S>А если без шуток, то имхо сегрегация конвеера — это тупиковый путь.

Да кто ж его специально сегрегирует. Вот только девелопера калачом не заманишь на роль PM. C Product Owner, конечно, все немного интереснее, но тут обратная проблема — тех кто хорошо умеет общаться с другими и среди общей массы то очень мало, а уж среди девелоперов вообще швах.

S>Тестеры, которые "без нас всё вообще умрёт", ожесточённо тестируют экзотические сценарии, забывая о банальностях.

Так надо начальником тестеров не ихнего специального сеньор QA, а тимлида, и проблема "тестируем не то" волшебным образом исчезнет.

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Да кто ж его специально сегрегирует.
Как кто? Решения о создании департаментов и принятии штатного расписания принимает непосредственное руководство.
НС>Вот только девелопера калачом не заманишь на роль PM.
А вот это непонятно. Ну, то есть понятно, что PMствовать должен экстраверт. Но в моей практике нормальных программистов-экстравертов мало, но достаточно.
Это, скажем так, неверная установка. Люди хотят копать "вглубь", думая, что это увеличивает их ценность как профессионалов.
Но мы сейчас живём в такое время, когда помнить наизусть штуки типа "как сделать компайл-тайм вычисления на взаимно-рекурсивных частично специализированных шаблонах" нафиг не надо.
Если ты в состоянии более-менее внятно сформулировать проблему, то её решение быстрее найти на stackoverflow, чем придумать самому. Это как помнить таблицу Unicode наизусть — не это делает человека разработчиком.

Важно обучать людей тому, что важно умение работать "поперёк", потому что многогранный специалист гораздо эффективнее самой классной команды в матричной структуре — тупо потому, что внутренняя речь быстрее речи вслух.
НС>Так надо начальником тестеров не ихнего специального сеньор QA, а тимлида, и проблема "тестируем не то" волшебным образом исчезнет.
Ты пойми, что без понимания общей задачи можно делать начальником тестеров кого угодно, и результат всё равно будет идиотическим.
Потому, что тимлид читает "...заказчик выбирает одну из сохранённых в системе кредитных карт..." Отлично! Влепим попап с выбором из списка и поиском! " ... или вводит данные для новой карты..." Отлично! Влепим попап с проперти гридом!.
Ставит задачу девелоперам; ставит задачу тестерам. Тестеры честно проверяют, что попапы показываются, и что нельзя уйти со страницы, не введя карту.
Потом тестеры с гордостью находят разнообразные контрпримеры, типа "на фаерфоксе 18 с отключенным жаваскриптом попап не срабатывает", или "если все сохранённые карты проекспайрились, то возникает unexpected end of list".
Никому и в голову не приходит спросить, а сколько % продаж идут через добавление новой карты, в скольки % используется единственная карта, в скольки % их две, и в скольки их 10 или больше. А чо? Сценарий покрыт, чего ещё.
Если маркетинг начинает пытаться им намекнуть, что надо бы оптимизироваться под наиболее частый сценарий, вводя обороты типа "использовать карту по умолчанию", то тимлид так и хреначит "ок, воткнём радио баттон: карта по умолчанию, новая карта, другая карта".
Идея "а давайте у нас специально обученные люди будут рисовать мокапы, а программисты потом будут их воплощать" — такое же зло, что и идея с выделением QA департамента.
В идеальном мире PM сам прототипирует UI прямо в библиотеке элементов, и вместо уродливых карандашных рисунков мы имеем 99% близкие к финалу формы. Выбрав наиболее понравившийся прототип, мы его обвязываем кодом.
Не обязательно всё это должен делать один и тот же человек, может и команда — но не функционально разделённая команда. Эффективнее будет, если 3 человека строчат каждый по функциональному фрагменту, чем когда мы имеем одного тестера, одного дизайнера, одного программиста, одного PM, и т.п.

Здравствуйте, Sinclair, Вы писали:

НС>>Вот только девелопера калачом не заманишь на роль PM.
S>А вот это непонятно.

А что тут непонятного? Зарплата та же, если не меньше. Работа скучная и нудная. Карьерные перспективы, конечно, получше, но рядовых девелоперов это, обычно, волнует слабо.

S> Ну, то есть понятно, что PMствовать должен экстраверт.

И это тоже.

S>Это, скажем так, неверная установка. Люди хотят копать "вглубь", думая, что это увеличивает их ценность как профессионалов.

Это у тебя какие то странные представления. Люди, как правило, хотят копать вглубь потому что интересно. А которые про ценность постоянно думают — эти да, этим пофик что делать. Вот только, как показывает практика, из таких и разработчкики фиговые, и ПМ.

S>Если ты в состоянии более-менее внятно сформулировать проблему, то её решение быстрее найти на stackoverflow, чем придумать самому.

В 95% случаев. Но есть еще 5, в которых SO тебя не спасет. Вроде и немного, но этих 5% вполне достаточно, чтобы проект у команды, состоящей из таких мелко плавающих спецов по SO либо встал, либо, что еще печальнее, дожил до релиза, а потом с ним в реальных условиях приключился нерековерабельный бада бум. И вот тут то у овнера и настает веселье, когда с одной стороны его задницу поджаривают сейлзы, у которых в момент демонстрации происходят внезапные факапчики, а с другой девелоперы с ПМом, которые разводят руками с выражением на лице в стиле "ну не шмогла я". После чего все великие спецы по SO в полном составе отправляются на выход.

S>Важно обучать людей тому, что важно умение работать "поперёк", потому что многогранный специалист гораздо эффективнее самой классной команды в матричной структуре — тупо потому, что внутренняя речь быстрее речи вслух.

Безусловно. Но это совсем другой вопрос.

НС>>Так надо начальником тестеров не ихнего специального сеньор QA, а тимлида, и проблема "тестируем не то" волшебным образом исчезнет.
S>Ты пойми, что без понимания общей задачи можно делать начальником тестеров кого угодно, и результат всё равно будет идиотическим.

Было бы странно, если бы тимлид ее не понимал. А вот в конторах где у тестеров свое начальство — вот там такое сплошь и рядом. Но выделенные тестеры это дорого, особенно если проектные команды небольшие, поэтому котята продолжают грызть кактус.

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

Это какой то странный тимлид. То ли молодой очень, то ли профнепригодный. Я уж не говорю о том, что чекать такие вещи на ранних этапах — прямая обязанность овнера.

S>Если маркетинг начинает пытаться им намекнуть

Маркетинг напрямую девелоперам, минуя овнера? Глупее придумать сложно.

S>В идеальном мире PM сам прототипирует UI

ПМ? Это вообще не его задача, это задача овнера. Задача ПМ (который Project) — обеспечить правильное планирование и эффективное использование ресурсов любыми способами. А прототипирование UI, хотя бы на уровне концепции — это, по сути, требования, и прямая обязанность product owner.

S>Не обязательно всё это должен делать один и тот же человек, может и команда — но не функционально разделённая команда. Эффективнее будет, если 3 человека строчат каждый по функциональному фрагменту, чем когда мы имеем одного тестера, одного дизайнера, одного программиста, одного PM, и т.п.

Зависит от размера команды. Ну и как то совмещение ПМ с чем то еще меня лично пугает — ничего хорошего из этого не выйдет. ПМ даже в небольшом проекте обычно загружен по самые яйца своими задачами.

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>А что тут непонятного? Зарплата та же, если не меньше. Работа скучная и нудная. Карьерные перспективы, конечно, получше, но рядовых девелоперов это, обычно, волнует слабо.
У нас ProdM не зарабатывают меньше девелоперов.
НС>Это у тебя какие то странные представления. Люди, как правило, хотят копать вглубь потому что интересно.
"интересность" — это очень странный параметр. Интересом нужно управлять. Без самоуправления, интерес вывозит человека в эксперта по сериалам и шаурме в окрестных киосках.
Мне вот интересно как делать хорошие продукты. И в это входит вообще всё — и алгоритмы в СУБД, и методики тестирования, и паттерны ООП, и когнитивная психология, и вопросы продуктизации.
Те, кто добровольно отказывается от чего-то из этого, мне непонятны.
НС>В 95% случаев. Но есть еще 5, в которых SO тебя не спасет. Вроде и немного, но этих 5% вполне достаточно, чтобы проект у команды, состоящей из таких мелко плавающих спецов по SO либо встал, либо, что еще печальнее, дожил до релиза, а потом с ним в реальных условиях приключился нерековерабельный бада бум.
А зачем "мелкоплавающих"? Пусть будут глубоко плавающие. Я про то, что надо знать основы — про управление сложностью, про взаимодействие компонентов, уметь быстро в голове построить модель параллельного исполнения кода.
Как ни удивительно, но очень часто бывает так, что разработчик, детально помнящий наизусть все примитивы современных агентно-ориентированных библиотек, в принципе не может вьехать в то, "как это между зачислением и списанием вклинится ещё одна операция".

НС>Было бы странно, если бы тимлид ее не понимал.
Да? А вот я сплошь и рядом встречаю результаты действий команд, в которых тимлид вообще не понял, про что его задача.
НС>Это какой то странный тимлид. То ли молодой очень, то ли профнепригодный.
Это стандартный тимлид, который мыслит категориями стандартной библиотеки компонентов. Таких, к сожалению, большинство.
НС>Я уж не говорю о том, что чекать такие вещи на ранних этапах — прямая обязанность овнера.
Судя по всему, вы овнером называете как раз того, кого у нас называют product manager.
S>>Если маркетинг начинает пытаться им намекнуть
НС>Маркетинг напрямую девелоперам, минуя овнера? Глупее придумать сложно.
Я говорю о Product Manager, который "из маркетинга", и сам ни строчки кода не может написать.
S>>В идеальном мире PM сам прототипирует UI
НС>ПМ? Это вообще не его задача, это задача овнера. Задача ПМ (который Project) — обеспечить правильное планирование и эффективное использование ресурсов любыми способами. А прототипирование UI, хотя бы на уровне концепции — это, по сути, требования, и прямая обязанность product owner.
Тогда мы об одном и том же. Вот у нас в компании мокапами занимается отдельная команда, а прототипирования нету вовсе.
НС>Зависит от размера команды. Ну и как то совмещение ПМ с чем то еще меня лично пугает — ничего хорошего из этого не выйдет. ПМ даже в небольшом проекте обычно загружен по самые яйца своими задачами.
Тот PM, про которого вы говорите — это администратор. От него вообще ничего не надо, кроме умения следить за расходниками и учётом рабочего времени. Я говорю про ProdM.

Здравствуйте, Sinclair, Вы писали:

НС>>А что тут непонятного? Зарплата та же, если не меньше. Работа скучная и нудная. Карьерные перспективы, конечно, получше, но рядовых девелоперов это, обычно, волнует слабо.
S>У нас ProdM не зарабатывают меньше девелоперов.

Под PM, если без расшифровки, обычно понимают Project Manager.

НС>>Это у тебя какие то странные представления. Люди, как правило, хотят копать вглубь потому что интересно.
S>"интересность" — это очень странный параметр. Интересом нужно управлять. Без самоуправления, интерес вывозит человека в эксперта по сериалам и шаурме в окрестных киосках.

Управлять то можно, но есть пределы, у каждого свои.

S>А зачем "мелкоплавающих"? Пусть будут глубоко плавающие.

А глубоко плавающие не только в гугле ответы на SO искать умеют. Ты ж сам написал сперва про то, что копать вглубь не надо.

S>Как ни удивительно, но очень часто бывает так, что разработчик, детально помнящий наизусть все примитивы современных агентно-ориентированных библиотек

Это ты называешь "копать вглубь"?

НС>>Было бы странно, если бы тимлид ее не понимал.
S>Да? А вот я сплошь и рядом встречаю результаты действий команд, в которых тимлид вообще не понял, про что его задача.

В такой ситуации твои рассуждения по поводу универсальности это примерно как починка небольшой течи в носу корабля, когда у тебя корму торпедой оторвало.

НС>>Это какой то странный тимлид. То ли молодой очень, то ли профнепригодный.
S>Это стандартный тимлид, который мыслит категориями стандартной библиотеки компонентов.

Это тогда не тимлид, а просто разработчик, даже не сеньор. Тимлид это уже не просто разработчик, более корректно эту должность обзывать developer manager. Чем то там управлять не понимая куда надо двигаться — какая то в высшей степени странная ситуация. Можно еще, к примеру, лобовое стекло затонировать не той стороной, а потом удивляться что ты далеко от стоянки не отъехал.

НС>>Я уж не говорю о том, что чекать такие вещи на ранних этапах — прямая обязанность овнера.
S>Судя по всему, вы овнером называете как раз того, кого у нас называют product manager.

Это примерно одно и тоже, просто owner это скрамовская терминология, несколько более узкое понятие.

НС>>Маркетинг напрямую девелоперам, минуя овнера? Глупее придумать сложно.
S>Я говорю о Product Manager, который "из маркетинга", и сам ни строчки кода не может написать.

Что то прям какие то чудеса ты описываешь. Тимлид, который не понимает куда идти, овнер, который из маркетинга ... Не, ну можно еще разработчиков набрать из Таджикистана, а на должность project manager посадить тупую блондинку секретаршу.

Здравствуйте, cocacola, Вы писали:

C>Привет! Раньше в it конторах хоть как то в респектах были разработчики.

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