Опять пожаловаться на начальника ...

[Херовимчик]

Все сомнительные вопросы нужно обсуждать письменно. Все что сказано устно на митинге, to follow up on a meeting discussion we are going to do a, b, c ... is it correct or I missing something?
Потом очень сложно в бутылку лезть

[vdfs]

Tread это нечто другое. Как вы код-то пишете для работы с потоками.

[Сабина]

Requirements надо собирать по крупицам - это неправильно и для большой фирмы и для маленькой . Начальник в этом смысле конечно может помочь enforce some rules.
Но это нормальный начальник, с опытом, с умением организовать cross team interactions чтобы собрать requirements и поставить правильного человека сделать хороший дизайн , РОС прежде чем всем бежать кодировать.
Именно в большом коллективе, где команды разбивают функционал на куски ( поддержка большого веб-сайта например) видно какой в каждом тиме начальник - по количеству багов, production incidents, по тому сколько этот тим проводит времени resolving prod oncall etc.
То есть суть начальника размером команды или компании не определяется как мне кажется

[nyekimov]

Requirements надо собирать по крупицам - это неправильно и для большой фирмы и для маленькой . Начальник в этом смысле конечно может помочь enforce some rules.
Но это нормальный начальник, с опытом, с умением организовать cross team interactions чтобы собрать requirements и поставить правильного человека сделать хороший дизайн , РОС прежде чем всем бежать кодировать.
Именно в большом коллективе, где команды разбивают функционал на куски ( поддержка большого веб-сайта например) видно какой в каждом тиме начальник - по количеству багов, production incidents, по тому сколько этот тим проводит времени resolving prod oncall etc.
То есть суть начальника размером команды или компании не определяется как мне кажется

Нет ну может у вас в компании может быть один начальник; который все держит в своих руках, но бывает еще и так, что есть пару человек, которые разбирают самые главные детали как Лиды, а дальше работает команда, иначе зачем команды нужны? Зачем вообще весь agile с постоянным фидбеком.
У нас больше ценится то, что каждый сениор может взять кусок и вникнуть во все детали, если нашёл какой edge case, и о нем как то забыли ввиду того, что система очень большая. То сениор должен сам найти ответ, задействовав нужных людей. Кое где роль утончения и документирования требований выполняет бизнес аналитик, но кое где их просто упростили.
На самой первой фирме консалтин шопе задачи давали уже разжеванные, все требования записаны. Только edge cases изредка вылезали в qa стадии. Хотя приложения там были элементарные и небольшие. Ну и оплата была намного ниже, чем в корпах, где у человека должен быть сильный опыт, чтобы просто въехать как работают модули между собой и быть готовым фиксить даже сторонний модуль, если он ломается где то на моменте интеграции. А модулей этих может быть просто дремучий лес, ведь разные Модули ещё писались в разное время.

[Херовимчик]

Но это нормальный начальник, с опытом, с умением организовать cross team interactions чтобы собрать requirements и поставить правильного человека сделать хороший дизайн , РОС прежде чем всем бежать кодировать.

Нормальный начальник делегирует эти процессы сеньорам+, собственно они для того и существуют в команде

[Sabrinna]

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