Ну сейчас довольно можно вести прямой контакт между разработчиком и клиентом, сильно снижает уровень бюрократии и ускоряет коммуникацию.
Ну и «такой ситуации не должно возникнуть» так себе логика. По ней и багов то быть не должно. Пони, радуга, рок-н-ролл.
заявить «у меня все работает» и «уточнять условия вопроизведения», «отреджектить тикет» это таки две большие разницы. Это может происходить одновременно, а может и не происходить. Тикет может висеть открытым годами, и по нему не будет ничего не происходить, потому что «у меня не воспроизводится», где подразумевается «фиг знает что с ним делать». Весьма распространенная ситуация. Видел такое в разных компаниях, в том числе крупных и известных.
Может. А может означать что ткнул пару раз, решил что муть какая-то и решил просто ничего не делать. А может там вся команда бьется над решением с привлечением смежных департаментов. Собственно это и значит что он не сообщает нужной вопрошающему информации. Вообще никакой кроме того, что судя по всему, что-то идет не так.
«О Великий Думатель, я хочу услышать ответ четкий и ясный, дай нам ответ на главный вопрос» (с)
Ну в примере очевидно вариант ответа клиенту. По этому ощущение шизофрении при ответе начальнику нормально.
Для ответа начальнику очевидно достаточно «сейчас работаю над этим». В случае критичности проблемы можно сказать «отложил остальные задачи, сейчас работаю только над этим».
Ну и нужно понимать это это воображаемый пример который просто иллюстрирует как может звучать ответ, который отражает информацию по важным аспектам. Естественно его нужно допилить по месту.
Как я уже сказал, нет никакого «нет» на пересечение зон ответственности. Его и быть не должно. И да, человек должен лезть повсюду. Если человек видит проблему, знает как и хочет ее исправить, ничего не должно ему мешать. Наоборот — все должны ему помогать. Это не так часто происходит как хотелось бы, что бы еще какие-то ограничения вводить.
У нас некоторые проекты ведут мидлы, т.е. они выступают в роли девлида. Но обычно, конечно, это небольшие проекты, простые, с совсем маленькой командой, или даже скорее вовсе без нее. Человек-проект.
Но и требования к мидлам (да и вообще ко всем разработчикам) достаточно серьезные.
Ну те доступы которые не выданы, ты вполне можешь запросить и получить. У нас нет вообще очень мало такого, что «тебе знать не положено». Любой человек может заниматься любыми вопросами. Это просто реальный пример по приведенному вами случаю, который приводился в пример, что «так не работает». Работает. И еще как. Не совсем так как приведено у вас конечно, но работает. Владелец выдает полномочия, когда ты сильно выходишь за рамки ответственности, и попадаешь на его «поле». Но если речь идет о бюджете департамента, то тоже будет происходить с руковдителем департамента.
Но границ нет. Есть зоны ответственности, но они никак не ограничивают в деятельности. Да, конечно, твои действия должны быть согласованы с тем, в чьих зонах ответственности ты действуешь, но это не граница, там нет запрета на пересечение.
Ну собственно речь о том, что «у меня работает» не может быть ответом. Может быть дополнительной информацией, пояснением к ответу, но самим ответом должно быть что-то другое. А иногда приходится сталкиваться с тем, что разработчик считает, что это может сойти именно за ответ.
Вы удивитесь, но у нас в компании у сотрудников таки есть доступы к бюджетом. И любой разработчик может прийти (в том числе и к владельцу), и выдвинуть свои предложения о том, как этим бюджетам следует распорядится.
И вполне возможна ситуация, что владелец скажет — окей, займись этим, т.е. выдаст ему все полномочия для проведения этих изменений. Для этого есть специальный механизм, и касается это даже джунов.
Так что вы несколько ошиблись в том, кто плавает в теме.
Ну на самом деле чем выше должность, чем больше тебе платят именно за знания, а не за деятельность. По сути по мере роста компании в сторону бирюзы (тут вроде оказалось достаточно много народу способных поддержать беседу в этом ключе), руководитель превращается из исполнителя в советника. И то чем он по сути занимается — это шарит знания, а не производит какую-то реальную работу. Они имеют гораздо большую ценность. Тимлид в таких структурах это самая верхняя из должностей кто реально еще может что-то делать руками, но должен уже стремится к тому, что бы перейти на следующую ступеньку, где ему этого не светит.
Ну а монструозные списки требований как правило вылезают из размазанных зон ответственности. По факту обычно не известно точно, что нужно. Есть некоторая дыра которую надо закрыть, и тут уж кого найдут — тем и закроют. Т.е. список требований — это список пожеланий и не нужно к нему подходить как то, что нужно реально все это знать. Как правило ожидают до 75% покрытия.
Ну, и опять же, планка критериев поиска всегда должна быть выше ожидаемого результата. Вы удивитесь по насколько безумным требованиям иногда удается находить реальных кандидатов, которые им удовлетворяют. А если не завышать ожидания, таких не найдешь.
Даже для играющего тренера, ожидать знания всех формул на зубок странно. И чем больше вы ожидаете от него как от тренера, тем меньше очевидно следует ожидать технических знаний.
Например если это тимлид плюс, который может уже не только тимлидить, а подхватывать и более высокоуровневые вопросы, то такой человек очевидно гораздо более ценен практически для любой компании. Таким подходом такие люди автоматом отсеиваются. А должно быть наоборот.
Там дело не только в высокой ответственности и количестве софт скилов, там вообще огромный спектр требований. Нужно до идеала надраить все предыдущие уровни — и иерархическое управление, и роль индивидуума, и культурный слой, шаринг знаний, список длинный. Но сейчас речь не об этом.
В бирюзовых организациях любой сотрудник имеет возможность проводить изменения любого уровня. По сути, даже джун, может проводить изменения на уровне компании, то что в классической схеме управления часто может сделать только владелец компании. Это таки очень сильно увеличивает степень ответственности на всех уровнях, особенно на низких (на высоких она наоборот снижается, происходит выравнивание).
Определенно больше понравиться, хоть он и по прежнему плох. Из ответа «не могу воспроизвести» следует, что он пытался воспроизвести и у него не получилось. Из ответа «у меня все работает» вообще ничего не следует.
Хороший ответ должен давать информацию по следующим аспектам:
1. Насколько плотно работают над проблемой?
2. Когда она будет решена?
3. Требуется ли что-то, для того что бы задача была решена или решена быстрее?
По сути это единственное что волнует клиента, и как следствие, должно волновать разработчика. Ответ «у меня все работает» не отвечает ни на один из аспектов, более того, создает впечатление негативных ответов. Похоже, над проблемой сейчас не производится никаких работ, и не похоже что кто-то что-то делал. Вариант «не могу воспроизвести», означает что по крайней мере кто-то что-то попытался сделать, но ситуация по прежнему не улучшается.
Идеальный ответ звучит так:
«Наши лучшие специалисты в настоящий момент плотно работают над этим, ожидаем решения в течении часа. Ребятам здорово поможет, если вы дополнительно предоставите следующую информацию:
1.…
2. ....»
Так и какое клиенту дело, что на машине разработчика работало/работает? Ему это чем поможет? Оно не работает у него, и только это его заботит.Единственное к чему она имеет отношение — к выяснению технических деталей инцидента. Но люди, которым этот ответ обычно дают, к такому выяснению обычно сами не причастны.
И да, «попробуйте еще раз через 5 минут» это допустимый ответ. «Выясняем, сообщу вам через час», тоже допустимо. А вот «у меня работает» это классический ответ по которому можно понять что работаешь с недостаточно квалифицированным человеком.
Не могу сказать что такая мысль меня не посетила в тот момент. Там было несколько других аспектов, которые наводили на мысль, что с собеседованием вообще что-то пошло не так. Так что я пообщался с HRом на тему не забыли ли они чего. Но вроде как нет, это «особенность политики найма». Бодаться с политиками найма крупных компаний при входе я нашел и неуместными и бесперспективными. Ну и честно говоря не уверен что хотел бы работать с командой, которую отбирали подобным образом.
К тому же по слухам зарплаты там были не особо высокие, да и в итоге на собеседования по сумме ушло больше 8 часов(только к ним), продолжать не похоже что имело смысл.
тут дело не столько в мультиклассовости, а в том что тимлид решает вопросы на другом уровне. Он оперирует архитектурой, и крупными блоками, не закапываясь в мелкие детали. Делает он это по прежнему руками (к примеру архитектор обычно уже нет). Тем не менее в детали обычно закапываются другие, за исключением случаев требующих особой квалификации или знаний. Это просто более высокий уровень абстракции, а не другой класс работы.
Хотя конечно, от компании зависит. Бывает по всякому.
Ну и «такой ситуации не должно возникнуть» так себе логика. По ней и багов то быть не должно. Пони, радуга, рок-н-ролл.
«О Великий Думатель, я хочу услышать ответ четкий и ясный, дай нам ответ на главный вопрос» (с)
Для ответа начальнику очевидно достаточно «сейчас работаю над этим». В случае критичности проблемы можно сказать «отложил остальные задачи, сейчас работаю только над этим».
Ну и нужно понимать это это воображаемый пример который просто иллюстрирует как может звучать ответ, который отражает информацию по важным аспектам. Естественно его нужно допилить по месту.
Но и требования к мидлам (да и вообще ко всем разработчикам) достаточно серьезные.
Но границ нет. Есть зоны ответственности, но они никак не ограничивают в деятельности. Да, конечно, твои действия должны быть согласованы с тем, в чьих зонах ответственности ты действуешь, но это не граница, там нет запрета на пересечение.
И вполне возможна ситуация, что владелец скажет — окей, займись этим, т.е. выдаст ему все полномочия для проведения этих изменений. Для этого есть специальный механизм, и касается это даже джунов.
Так что вы несколько ошиблись в том, кто плавает в теме.
Ну а монструозные списки требований как правило вылезают из размазанных зон ответственности. По факту обычно не известно точно, что нужно. Есть некоторая дыра которую надо закрыть, и тут уж кого найдут — тем и закроют. Т.е. список требований — это список пожеланий и не нужно к нему подходить как то, что нужно реально все это знать. Как правило ожидают до 75% покрытия.
Ну, и опять же, планка критериев поиска всегда должна быть выше ожидаемого результата. Вы удивитесь по насколько безумным требованиям иногда удается находить реальных кандидатов, которые им удовлетворяют. А если не завышать ожидания, таких не найдешь.
Например если это тимлид плюс, который может уже не только тимлидить, а подхватывать и более высокоуровневые вопросы, то такой человек очевидно гораздо более ценен практически для любой компании. Таким подходом такие люди автоматом отсеиваются. А должно быть наоборот.
В бирюзовых организациях любой сотрудник имеет возможность проводить изменения любого уровня. По сути, даже джун, может проводить изменения на уровне компании, то что в классической схеме управления часто может сделать только владелец компании. Это таки очень сильно увеличивает степень ответственности на всех уровнях, особенно на низких (на высоких она наоборот снижается, происходит выравнивание).
Хороший ответ должен давать информацию по следующим аспектам:
1. Насколько плотно работают над проблемой?
2. Когда она будет решена?
3. Требуется ли что-то, для того что бы задача была решена или решена быстрее?
По сути это единственное что волнует клиента, и как следствие, должно волновать разработчика. Ответ «у меня все работает» не отвечает ни на один из аспектов, более того, создает впечатление негативных ответов. Похоже, над проблемой сейчас не производится никаких работ, и не похоже что кто-то что-то делал. Вариант «не могу воспроизвести», означает что по крайней мере кто-то что-то попытался сделать, но ситуация по прежнему не улучшается.
Идеальный ответ звучит так:
«Наши лучшие специалисты в настоящий момент плотно работают над этим, ожидаем решения в течении часа. Ребятам здорово поможет, если вы дополнительно предоставите следующую информацию:
1.…
2. ....»
И да, «попробуйте еще раз через 5 минут» это допустимый ответ. «Выясняем, сообщу вам через час», тоже допустимо. А вот «у меня работает» это классический ответ по которому можно понять что работаешь с недостаточно квалифицированным человеком.
К тому же по слухам зарплаты там были не особо высокие, да и в итоге на собеседования по сумме ушло больше 8 часов(только к ним), продолжать не похоже что имело смысл.
Хотя конечно, от компании зависит. Бывает по всякому.