Пару слов о стиле работы. Стиль работы такой же как во всей стране - не напрягающий и очень дружелюбный. Я до сих пор не знаю как они все успевают делать с таким коротким рабочим днем, но факт остается фактом.
Причем дружелюбие и спокойствие тут ценятся очень сильно. Где-то я даже прочитала, что тут крайне отрицательно относятся к замученным лицам. Считается, что если тебе сложно, то ты должен спокойно предпринимать попытки разрешить ситуацию и не стесняться спрашивать помощь. Думаю никто не любит работать в поддержке и помогать людям решать проблемы их кривых рук, но тут это часть работы каждого.
Сегодня у меня была забавная консультация с менеджером смежного подразделения. Мне нужно по задаче добавить в подведомственную его команде часть некоторые важные изменения. Мужчина был очень приветлив, очень подробно объяснил мне всю архитектуру, правила и принципы работы. Пол часа он мне показывал что, где, почему и как можно, а как нельзя. После того, как стало понятно кто и что будет делать дальше, он пошел дальше по делам.
Отличный человек, очень дружелюбный, очень подробно и понятно объясняет. Душка, а не начальник, надо сказать я два дня ждала, пока он освободиться для этого разговора. И только после его ухода мой коллега объяснил мне, что он совсем не в восторге, что мы собираемся переделывать их стабильную систему. Но никакого негатива. Совсем.
Я даже специально сегодня спрашивала, как у нас принято решать конфликты. Мне пришлось даже приводить специальную ситуацию, потому что иначе люди не поняли, о чем идет речь. Вообщем, при прохождении code review (анализ написанного кода) ты обязан исправить замечания, которые указывают на появление ошибок или уязвимости. Если замечания связаны с оформлением или личными предпочтениями, то тут задача редактора убедить в своей правоте. Получится - будет по твоему, нет - на нет и суда нет. Хотя тут есть один тонкий момент, нельзя добавить в релиз код с warnings (замечаниями), так что особо напакостить не удастся.
А ответственность тут разделяется как по книжке - менеджер проекта определяет список функций и как то, как он видит из работу и выполнение, а разработчик/тестировщик отвечают за качество реализации. Все просто. Если менеджер проекта просит что-то несуразное, то его задача убедить разработчика в том, что это действиетльно необходимо клиенту. Например у меня была задача, в которой было написано, что я должна добавить в определенную библиотеку некоторые методы. Как я потом выяснила это серьезно нарушало архитектуру приложения и инкапсуляцию слоев приложения. Все что потребовалось - уточнить цель задачи и найти средства реализовать эту цель в рамках архитектуры. Пришлось добавить другие методы в другой слой.