Если мягко сказать, то автор не совсем прав.
Делать то, что хочешь, дают. Просто как в любой бизнес компании есть приоритетные задачи, а есть просто хотелки. В первую очередь, акцент при разработке делается на приоритетные задачи, а уже потом на все остальное. Если автору не дали добро на то, что хотел сделать он и в чем он дока, то возможно задача не была столь необходимой.
Ошибки надо править не 2 штуки в неделю, а так, чтобы соблюдать сроки их исправления. Ошибки в разных статусах и соответственно имеют разный срок отработки. Если срок отработки ошибки просрочен, сразу попадаешь под раздачу от руководителя.
Вообще в описании крайне странно выглядит подход автора, что его должны контролировать и пинать. В 1С приходят взрослые самостоятельные люди. Готовые сами выстраивать свой план работ, работать самостоятельно. Руководитель лишь назначает направление и расставляет приоритеты. И тут уже вопрос к автору, что он не может работать без пинков и самостоятельно выстраивать свой рабочий процесс.
В группе, в которой работал автор, людей вообще не много, и там как таковых лидов нет. Там каждый тянет свой блок.
Код ревью есть. Есть АПК, автоматизированная проверка конфигураций, есть CI тесты и т.д. и т.п., поэтому тут автор в корне не прав.
Про взаимопомощь, автор тоже не прав. Всегда можно подойти к другим разработчикам и узнать, как лучше сделать. Если тебе не сказали это прямо сейчас, то возможно человек занят и стоит подойти чуть позже. Но такого, что тебя посылают нет и в помине.
Опять же, автор пишет, что стандарты разработки и написания коды закрыты, а это не так. На ИТС стандарты опубликованы и каждый желающий может их читать, изучать и разрабатывать свой код, именно с учетом этих рекомендаций и требований.
Резюмируя, в статье много не правды и лукавства.
Делать то, что хочешь, дают. Просто как в любой бизнес компании есть приоритетные задачи, а есть просто хотелки. В первую очередь, акцент при разработке делается на приоритетные задачи, а уже потом на все остальное. Если автору не дали добро на то, что хотел сделать он и в чем он дока, то возможно задача не была столь необходимой.
Ошибки надо править не 2 штуки в неделю, а так, чтобы соблюдать сроки их исправления. Ошибки в разных статусах и соответственно имеют разный срок отработки. Если срок отработки ошибки просрочен, сразу попадаешь под раздачу от руководителя.
Вообще в описании крайне странно выглядит подход автора, что его должны контролировать и пинать. В 1С приходят взрослые самостоятельные люди. Готовые сами выстраивать свой план работ, работать самостоятельно. Руководитель лишь назначает направление и расставляет приоритеты. И тут уже вопрос к автору, что он не может работать без пинков и самостоятельно выстраивать свой рабочий процесс.
В группе, в которой работал автор, людей вообще не много, и там как таковых лидов нет. Там каждый тянет свой блок.
Код ревью есть. Есть АПК, автоматизированная проверка конфигураций, есть CI тесты и т.д. и т.п., поэтому тут автор в корне не прав.
Про взаимопомощь, автор тоже не прав. Всегда можно подойти к другим разработчикам и узнать, как лучше сделать. Если тебе не сказали это прямо сейчас, то возможно человек занят и стоит подойти чуть позже. Но такого, что тебя посылают нет и в помине.
Опять же, автор пишет, что стандарты разработки и написания коды закрыты, а это не так. На ИТС стандарты опубликованы и каждый желающий может их читать, изучать и разрабатывать свой код, именно с учетом этих рекомендаций и требований.
Резюмируя, в статье много не правды и лукавства.