В 1С прижилась странная штука - архитектор бывает «функциональный» и «технический», как будто это две разные профессии. У программистов такого раскола нет, у тестировщиков нет, а у архитекторов - есть. Откуда он взялся именно в таком виде и почему именно сейчас становится только актуальнее? Можно конечно сказать - «так сложилось», но мне интересно, почему все-таки сложилось именно так. За этим стоит конкретная логика, ее корни - вообще не в мире разработки.
Сотрудникам объяснили новый порядок, показали его пользу и получили согласие. Но в реальных задачах они продолжили работать по-старому. Разбираемся, почему понимание правила не гарантирует его выполнения и что руководителю проверять перед очередным напоминанием.
Руководитель редко одинаково хорошо добивается результата, выстраивает процессы, запускает изменения и работает с людьми. Проблема возникает, когда его личные слабости превращаются в ограничения всего подразделения. Разбираю, как найти недостающую управленческую функцию и закрыть её через людей, процессы и полномочия.
Сотрудник может согласовывать каждую мелочь с руководителем. Возможно, самостоятельность в этой команде стала слишком рискованной. Бывает и обратная ситуация: задачу передали не определив границ, полномочий и понятного результата. Разбираем две управленческие крайности и то, что стоит проверить до разговора о недостатке ответственности.
Продолжаю разбирать профстандарты. Беру стандарт «Архитектор программного обеспечения» (06.003) и сверяю с тем, кого у нас в 1С зовут архитектором. Зовут кого угодно - спеца по производительности, тимлида, ревьювера, самого опытного на проекте, - но почти никогда того, кто на самом деле делает работу архитектора. А она одна: принимать архитектурные решения и отвечать за них.