Comments 18
4. ПМ никогда не узнает точно за сколько по времени можно выполнить задачу)
Кажется, мы не до конца поняли вопрос. Раскройте вашу мысль, пожалуйста.
Вольно цитирую супругу, она ПМ в разработке: «Конечно, я сама никогда не определю, за сколько времени можно запрограммировать ту или иную фичу. Но я знаю всех своих разработчиков, и знаю, что от каждого ожидать. Паша оценивает срок относительно точно, а то, что оценил Юра, всегда нужно умножать на два».
Речь, вероятно про архитектуру инфраструктуры. Здесь архитектор работает с ИТ-подразделением заказчика. Видимо поэтому вы «пустили вперёд» аналитика, а затем уже архитектора. Если Архитектор с большой буквы «А» и действительно системный (системный подход) далее СА, то аналитик для него такой же ресурс, как и проектировщик. Он получает задачу от СА на исследование предметной области заказчика на уровне бизнеса (процессы, цели, задачи). На основании результатов, СА предлагает верхнеуровневое решение декомпозированное по задачам для проектировщиков.
Главные задачи, которые решает СА:
1. Соответствие решения(результата проекта) требованиям заказчика (решение бизнес-задачи заказчика)
2. Декомпозиция работ между исполнителями (собственными и подрядными) и авторский надзор
3. Контроль работоспособности и качества решения в целом
4. Оптимизация стоимости решения
В остальном соглашусь, особенно про структуру проекта и план. Без СА РП не в состоянии управлять сложным комплексным проектом.
Главные задачи, которые решает СА:
1. Соответствие решения(результата проекта) требованиям заказчика (решение бизнес-задачи заказчика)
2. Декомпозиция работ между исполнителями (собственными и подрядными) и авторский надзор
3. Контроль работоспособности и качества решения в целом
4. Оптимизация стоимости решения
В остальном соглашусь, особенно про структуру проекта и план. Без СА РП не в состоянии управлять сложным комплексным проектом.
Вокруг понятия «системный архитектор» существует много терминологической путаницы, более связанной с личным кругозором или комплексом решаемых задач теми, кто его употребляет. Поэтому сразу же следует отметить, что термин «системный» может происходить от двух понятий — собственно система и системный подход, что в современном мире отнюдь далеко не одно и то же. Поэтому при любом разговоре о системных архитекторах (а это весьма важная тема для всех сегментов рынка) следует вначале уточнить, о каких именно архитекторах идет речь.
Помимо специалистов по конкретным решениям конкретных поставщиков можно встретить архитекторов по конкретным технологиям и по сервисам, по безопасности и по приложениям, по конкретным направлениям или по какой-либо предметной области, по телекоммуникациям и по ИТ, по системам управления и по ПО, по ИТ- и по бизнес-процессам, по инфраструктуре и по интеграции, по технике и по функциональным решениям. Локально каждого из них могут даже называть системным архитектором, но это будет соответствовать истине только в случае, если кроме ниши, в которой работает данный архитектор, в проекте ничего больше нет. В противном случае кто-то другой должен будет находиться на вершине, с которой виден весь проект во всем разнообразии решаемых задач. Это и будет «настоящий» системный архитектор.
А вот знать он должен, прежде всего, что такое системный подход и системный анализ, а также обладать системоинженерным мышлением.
Что касается системной инженерии, то это способы создания успешной системы (то есть удовлетворяющей все потребности заказчиков, пользователей и прочих имеющих отношение к системе стейкхолдеров) на базе междисциплинарного подхода, означающего работу с различными инженерными специальностями.
Система может представлять собой все что угодно от комплекса информационных систем до целых промышленных предприятий (промышленных групп) со всеми входящими, включая технологические и производственные процессы, логистику, бизнес-процессы, а также оборудование и здания. Междисциплинарный подход подразумевает работу отнюдь не только исключительно с инженерными специальностями, а вообще с любыми специальностями, которые будут необходимы для реализации той или иной системы (проекта).
Помимо указанного системному архитектору необходим опыт как реализации успешных систем, так и ошибок (разумеется, не только своих). Поэтому на становление настоящего системного архитектора порой уходит целая жизнь.
Ничуть не пытаясь хоть как-то принизить значение и достижения множества молодых специалистов, грезящих превращением в настоящих системных архитекторов, «редкая птица» из последних бывает моложе 30 лет.
Поэтому чтобы стать настоящим системным архитектором надо учиться, учиться и еще раз учиться!
Помимо специалистов по конкретным решениям конкретных поставщиков можно встретить архитекторов по конкретным технологиям и по сервисам, по безопасности и по приложениям, по конкретным направлениям или по какой-либо предметной области, по телекоммуникациям и по ИТ, по системам управления и по ПО, по ИТ- и по бизнес-процессам, по инфраструктуре и по интеграции, по технике и по функциональным решениям. Локально каждого из них могут даже называть системным архитектором, но это будет соответствовать истине только в случае, если кроме ниши, в которой работает данный архитектор, в проекте ничего больше нет. В противном случае кто-то другой должен будет находиться на вершине, с которой виден весь проект во всем разнообразии решаемых задач. Это и будет «настоящий» системный архитектор.
А вот знать он должен, прежде всего, что такое системный подход и системный анализ, а также обладать системоинженерным мышлением.
Что касается системной инженерии, то это способы создания успешной системы (то есть удовлетворяющей все потребности заказчиков, пользователей и прочих имеющих отношение к системе стейкхолдеров) на базе междисциплинарного подхода, означающего работу с различными инженерными специальностями.
Система может представлять собой все что угодно от комплекса информационных систем до целых промышленных предприятий (промышленных групп) со всеми входящими, включая технологические и производственные процессы, логистику, бизнес-процессы, а также оборудование и здания. Междисциплинарный подход подразумевает работу отнюдь не только исключительно с инженерными специальностями, а вообще с любыми специальностями, которые будут необходимы для реализации той или иной системы (проекта).
Помимо указанного системному архитектору необходим опыт как реализации успешных систем, так и ошибок (разумеется, не только своих). Поэтому на становление настоящего системного архитектора порой уходит целая жизнь.
Ничуть не пытаясь хоть как-то принизить значение и достижения множества молодых специалистов, грезящих превращением в настоящих системных архитекторов, «редкая птица» из последних бывает моложе 30 лет.
Поэтому чтобы стать настоящим системным архитектором надо учиться, учиться и еще раз учиться!
Вот очень хочется мне найти себе наставника в виде опытного СА, да у нас таких в общем то и нет, а учиться у кого то надо :(
Хотя, например, я часто в процессе встречаюсь с тем, что «сейлзы» как раз знают, на какие встречи нужен архитектор, чтобы рисовать в воздухе правильные узоры пальцами — и берут с собой к заказчику.
Как это знакомо
Вот у нас как раз сидит Петров, он наш лучший специалист в области рисования красных линий. Мы его специально пригласили на совещание, чтобы он высказал свое компетентное мнение.
Хорошо бы сделать чек-лист компетенций архитектора, с комментариями. Это покроет запрос тех, кто желает развиваться, да и для проверки и выявления слабых мест удобно.
Я бы почитал подобное, но сам написать не могу — некомпетентен
Я бы почитал подобное, но сам написать не могу — некомпетентен
Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание.
Я как-то был всегда уверен, что Техническое Задание пишет Заказчик, а не Исполнитель…
Хотя если нацеленность на успех в проекте, то можно и помочь ему написать ТЗ до тендера. Там и смотреть на требования становится легче и сжатые сроки сразу соблюдаются.
Техническое задание пишет тот, насчет кого договорились. Но чаще исполнитель, как полностью владеющий темой (знанием о возможностях продукта), и потом согласовывается.
Зависит от многих факторов. Например, если заказчик обращается к исполнителю с разработкой новой системы, то ТЗ может исходить от него. Или если ему нужно реализовать подсистему у него уже есть ряд наследных требований
Зависит от многих факторов. Например, если заказчик обращается к исполнителю с разработкой новой системы, то ТЗ может исходить от него. Или если ему нужно реализовать подсистему у него уже есть ряд наследных требований
Я как-то был всегда уверен, что Техническое Задание пишет Заказчик, а не Исполнитель…Я как-то чаще видел заказчиков, которым ТЗ пишет исполнитель. Некоторым и тендерные требования приходилось писать, по которым будущий исполнитель выбирался…
Про презентации нужно написать отдельный пост. Я так и не нашел решение делемы, которую попробую пояснить в следующем абзаце:
Как архитектор решения описываю все что касается и будет (или не будет) входить в скоуп проекта. С другой стороны нужна декомпозиция задач для отдельных групп разработки. Задачи спускаются проектировщикам и те описывают детальное ТЗ, которое возвращается мне на проверку. Задачи проектировщикам достаточно узкие, но чтоб правильно проектировать систему нужно знать не только на вопрос «Что?» (по сути это есть в постановке задачи) но и «Зачем?» (все что снаружи).
Так вот — общая презентация проекта всем разработчикам это абсолютно провальное мероприятие (по крайней мере у меня) т.к никто не понимает что из этого его и не может внятно сформулировать вопросы. Презентация задач для проектировщика конкретной системы тоже не всегда удачно — проектировщик часто либо выпрашивают малейшие детали — фактически мы проектируем систему вместе либо проектируют систему не правильно т.к не смогли словить контекст (я возвращаю их ТЗ обратно и так пару десятков итераций что равно по времени совместному проектированию).
Пару раз делал эксперимент описывать задачу вместе с контекстом, при этом пытаясь выбрать правильный контекст. Тут ситуация с проектированием по лучше — проектировщик знает все что ему необходимо в отдельном документе. Но на выбор нужного контекста, описание и презентацию задач каждой группе разработки в отдельности уходит слишком много времени.
Хотелось бы чтоб автор статьи поделился своим опытом в данном направлении.
P.s Если у вас есть позиция архитектора в Украине с экспертизой в области ERP систем ритейла я бы рад сотрудничать с вами
Как архитектор решения описываю все что касается и будет (или не будет) входить в скоуп проекта. С другой стороны нужна декомпозиция задач для отдельных групп разработки. Задачи спускаются проектировщикам и те описывают детальное ТЗ, которое возвращается мне на проверку. Задачи проектировщикам достаточно узкие, но чтоб правильно проектировать систему нужно знать не только на вопрос «Что?» (по сути это есть в постановке задачи) но и «Зачем?» (все что снаружи).
Так вот — общая презентация проекта всем разработчикам это абсолютно провальное мероприятие (по крайней мере у меня) т.к никто не понимает что из этого его и не может внятно сформулировать вопросы. Презентация задач для проектировщика конкретной системы тоже не всегда удачно — проектировщик часто либо выпрашивают малейшие детали — фактически мы проектируем систему вместе либо проектируют систему не правильно т.к не смогли словить контекст (я возвращаю их ТЗ обратно и так пару десятков итераций что равно по времени совместному проектированию).
Пару раз делал эксперимент описывать задачу вместе с контекстом, при этом пытаясь выбрать правильный контекст. Тут ситуация с проектированием по лучше — проектировщик знает все что ему необходимо в отдельном документе. Но на выбор нужного контекста, описание и презентацию задач каждой группе разработки в отдельности уходит слишком много времени.
Хотелось бы чтоб автор статьи поделился своим опытом в данном направлении.
P.s Если у вас есть позиция архитектора в Украине с экспертизой в области ERP систем ритейла я бы рад сотрудничать с вами
UFO just landed and posted this here
По нашему опыту нужно обязательно делать общую встречу, можно презентацию, для всей рабочей группы на старте проекта. По ходу проекта обязательно нужно собираться и делиться статусами. Важно поддерживать у всего коллектива одинаковое понимание ситуации, задач заказчика, последних вводных и так далее. В дополнение к этим встречам нужно ставить отдельное ТЗ каждому участнику. То есть не нужно выбирать что-то одно. И ещё обязательно нужно делать матрицу, где весь проект бить на задачи, каждую задачу приписывать конкретному исполнителю. Эта матрица всегда должна быть доступна всем участникам. Как-то так. А насчет вашего P.S., предлагаем вам написать сюда ISapozhnikova@technoserv.com, это мейл нашей коллеги из HR.
Sign up to leave a comment.
Что нужно знать, чтобы стать системным архитектором