Я описал иную ситуацию. Как раз с определение какие фичи будут реализованы, а какие «завихрения» клиентов останутся без ответа — такие решения принимаются без проблем. Проблемы дальше, когда выбранную фичу надо реализовать.
И пул фичей, которые надо реализовать — велик. Без работы сидеть не приходилось вообще.
Собственно я об этом и писал. В моем понимании — это должен делать аналитик, он также должен состыковывать хотелки, чтобы то, что надо было одному отделу разработку не порушило работу другого отдела. И monkey-кодерс тут не при чем.
А если это все взвалить на разработчика… Получается, что такой разработчик должен все скилы C++ иметь, а также прикладную разработку, а также UX, а также глубоко (а не на уровне блоков) знать взаимодействие всех подсистем платформы, либо разбираться в них «на марше».
Нормально там платят, я бы даже сказал, что хорошо и ОЧЕНЬ хорошо, и премии дают. И «голодных игр» в столовой никогда не было. И кормят там завтраком, обедом, и если надо, то и ужином.
Коллеги, вы не поверите, но сегодня мне написал один очень-очень и очень уважаемый мной ранее коллега, который сейчас работает в 1С и потребовал прекратить писать гадости, ибо это порождает негатив и сотрудников набирать сложнее, и вообще нехорошо с людьми ссориться. Вот так-то…
Моя реплика была не в твой адрес, а в адрес EvilBeaver.
Я не знаю, как именно разрабатываются прикладные конфигурации, но я как С++ разработчик не являюсь спецом в разработке конфигураций.
Но когда ставится задача: «У объекта такого-то должно появиться такое-то свойство, которое должно влиять на то-то» это означает, что разработчик платформы должен знать — как разработчики конфигураций будут его использовать и для чего — для каких кейсов предполагается использовать это свойство. Ты идешь к разработчикам конфигурации и интересуешься их хотелками, а они говорят, что им это свойство ни в… не впилось, и они хотят этот кейс решать иначе, но твой руководитель говорит — «сделай просто целочисленное». Ну ок, делаешь целочисленное, закрываешь задачу, а потом тебе прилетает, что свойство-то надо было добавить еще и к такому-то объекту, чтобы было все аналогично, и свойство формы надо сделать, и сделать его в форме надо было так-то, поскольку оно не будет часто используемым. И команда, рулящая этим свойством нужна совсем не в той группе. Ты офигиваешь, и в рамках баги переделываешь под новые воводные, а потом самый большой начальник говорит: «Хрен ли ты столько времени делал задачу? Я вообще планировал, что ты на неё потратишь 2 часа вместе с анализом». Замечу, что про 2 часа и про то, что именно хотел самый большой начальник ты узнаешь, когда релиз уже надо выпускать.
Я, как бывший разработчик технологической платформы, могу сказать, что автору крупно повезло, что он обошелся «почти без переработок». В большинстве отделов переработки (бесплатные, разумеется, за идею) не то, что приветствуются, а являются обязательными.
Что касается соцпакета — это оплата больничных в 50, 75 и 100% размере от ЗП, причем заранее насколько тебе оплатят больничный предугадать невозможно — это на субъективное усмотрение руководства.
То, что нет архитекторов, аналитиков и др… Руководство считает, что таким образом разработчикам будет интереснее, поскольку он сам анализирует, создает архитектуру, кодит, а иногда и тестирует фичу. В условиях отсутствия документации это довольно сложно.
Проектные документы описывают поведение фичи для конечного пользователя (если это касается GUI) или разработчика конфигурации (если это внутриплатформенная фича), лишь иногда описывают детали внутренней архитектуры, чаще — только отдельные моменты.
Передача знаний осуществляется вербально. Если сотрудник, отвечающий за какой-то функционал в отпуске/заболел/уволился/умер — знания восстанавливаются обратным инженерингом.
Пробовал я стрясти какие-то деньги с почты как покупатель, все что добился — официальный ответ, де до момента вручения владельцем является отправитель, только он должен подавать на розыск. Поэтому или PayPal или иная служба защиты покупателя (как например для Visa Gold/Platinum) или все… ушли деньги.
И пул фичей, которые надо реализовать — велик. Без работы сидеть не приходилось вообще.
А если это все взвалить на разработчика… Получается, что такой разработчик должен все скилы C++ иметь, а также прикладную разработку, а также UX, а также глубоко (а не на уровне блоков) знать взаимодействие всех подсистем платформы, либо разбираться в них «на марше».
Я не знаю, как именно разрабатываются прикладные конфигурации, но я как С++ разработчик не являюсь спецом в разработке конфигураций.
Но когда ставится задача: «У объекта такого-то должно появиться такое-то свойство, которое должно влиять на то-то» это означает, что разработчик платформы должен знать — как разработчики конфигураций будут его использовать и для чего — для каких кейсов предполагается использовать это свойство. Ты идешь к разработчикам конфигурации и интересуешься их хотелками, а они говорят, что им это свойство ни в… не впилось, и они хотят этот кейс решать иначе, но твой руководитель говорит — «сделай просто целочисленное». Ну ок, делаешь целочисленное, закрываешь задачу, а потом тебе прилетает, что свойство-то надо было добавить еще и к такому-то объекту, чтобы было все аналогично, и свойство формы надо сделать, и сделать его в форме надо было так-то, поскольку оно не будет часто используемым. И команда, рулящая этим свойством нужна совсем не в той группе. Ты офигиваешь, и в рамках баги переделываешь под новые воводные, а потом самый большой начальник говорит: «Хрен ли ты столько времени делал задачу? Я вообще планировал, что ты на неё потратишь 2 часа вместе с анализом». Замечу, что про 2 часа и про то, что именно хотел самый большой начальник ты узнаешь, когда релиз уже надо выпускать.
Что касается соцпакета — это оплата больничных в 50, 75 и 100% размере от ЗП, причем заранее насколько тебе оплатят больничный предугадать невозможно — это на субъективное усмотрение руководства.
То, что нет архитекторов, аналитиков и др… Руководство считает, что таким образом разработчикам будет интереснее, поскольку он сам анализирует, создает архитектуру, кодит, а иногда и тестирует фичу. В условиях отсутствия документации это довольно сложно.
Проектные документы описывают поведение фичи для конечного пользователя (если это касается GUI) или разработчика конфигурации (если это внутриплатформенная фича), лишь иногда описывают детали внутренней архитектуры, чаще — только отдельные моменты.
Передача знаний осуществляется вербально. Если сотрудник, отвечающий за какой-то функционал в отпуске/заболел/уволился/умер — знания восстанавливаются обратным инженерингом.