Кто такой архитектор? Системный или функциональный? Статья 1

Публикация № 1257685

Методология - Проектирование

Архитектор системный архитектор функциональный качество разработки разработка проект программирование управление проектом.

В связи с повальным непониманием того, как устроен процесс разработки в сфере 1С и кто за что отвечает, будут написаны 8 статей. Это первая статья. Она очень актуальна, т.к. многие проектные команды не имеют архитектора, либо используют его не по назначению. В этой статье раскрываю роль архитектора и его значимость. Основываюсь на своём опыте (более 10 лет), также изучал статьи на эту тему от коллег и консультировался с руководителями крупных команд. В данной статье будут раскрыты следующие вопросы: 1. Кто такой архитектор? 2. Какие задачи выполняет архитектор? 3. Можно ли без него обойтись? 4. Чем отличается системный архитектор от функционального архитектора? 5. Кто главный: РП или архитектор? Кому подчиняется проектная команда?
  1. Кто такой архитектор?

 

Для того чтобы ответить на это вопрос, надо дать определение архитектуры.

 

Архитектура программного обеспечения – это совокупность важнейших решений об организации программной системы. Состоит из:

    • Выбора структурных элементов и их интерфейсов, с помощью которых составлена система, их поведение в рамках сотрудничества структурных элементов.
    • Соединения выбранных элементов структура в более крупные системы.
    • Архитектурного стиля, который направляет все элементы, их интерфейсы, сотрудничество и соединение.

 

Данное определение можно найти в интернете. Переведем это на язык 1С!

  • Архитектор определяет состав и структуру объектов метаданных и взаимосвязи между всеми объектами метаданных в рамках каждой отдельной подсистемы.
  • Каждое решение состоит из подсистем. Состав каждой подсистемы и взаимодействие между подсистемами определяет архитектор.
  • Архитектор определяет, с помощью каких объектов метаданных решать ту или иную задачу, насколько глубоко необходимо переработать типовое решение, какие объекты метаданных сделать новыми. Определяет подходы к разработке интерфейсов. Определяет сценарии работы каждого объекта метаданных.

 

Как видно из определения и его перевода на язык 1С, архитектор – это ключевая фигура на проекте. Архитектор отвечает за всё. От него зависит:

  • Структура метаданных
  • Функциональность системы
  • Отказоустойчивость системы
  • Удобство использования системы
  • Быстродействие системы
  • Простота сопровождения

 

  1. Какие задачи выполняет архитектор?

 

После того, как разобрались кто такой архитектор, можно подумать о его задачах. Главными задачами архитектора являются (в части постановки задач):

  • Выяснение у заказчика требований к автоматизации бизнес-процессов (итерационная задача).
  • Определение структуры метаданных в целом и каждого объекта метаданных в частности.
  • Определение связей между объектами метаданных.
  • Наполнение системы новыми сценариями.

 

Для достижения отказоустойчивости, удобства использования, быстродействия, простоты сопровождения архитектор выполняет следующие задачи (в части приемки работ):

  • Разъяснение членам команды постановки задачи и сценариев.
  • Обсуждение способа реализации (Design review).
  • Проверка реализации (Code review).
  • Организация внутреннего тестирования. Проверка протокола тестирования.
  • Включение доработки в релиз.

 

  1. Чего архитектор НЕ должен делать?

 

Часто на проектах нерадивые руководители скидывают на архитектора следующие задачи:

  • Планирование сроков разработки... Да архитектор определяет что, как и в какой последовательности делать, но пока не описана архитектура и не определены сценарии угадать срок разработки невозможно. В целом планирование – это задача РП. Архитектор здесь выступает только как эксперт, но не как составитель план-графика! О сроках подробнее ниже…
  • Контроль сроков разработки по каждой задаче. Некоторые руководители думают, что обзвонить всех разработчиков и консультантов каждый день это задача архитектора. Это опять роль РП или помощника РП. Архитектору этим некогда заниматься!
  • Архитектор не должен убеждать членов команды (даже вышестоящих) в правильности своего решения. У всех членов команды разный уровень знаний и опыт работы. Архитектор (в нормальном виде) – это самый грамотный и самый опытный. Это человек, который в голове держит всю картину проекта и знающий, что как и с чем связано. Отступление от плана архитектора грозит разрухой в архитектуре.

 

  1. Можно ли без него обойтись?

 

Для ответа на этот вопрос необходимо проанализировать каждую задачу архитектора и найти на неё исполнителя. Главное обеспечить такое же качество выполнения этой задачи на уровне архитектора!

  • Выяснение требований. Часто эту задачу поручают аналитикам или консультантам. В одной из следующих статей будут описаны компетенции членов команды. Для выяснения требований надо знать и существующую архитектуру решения, и сценарии и особенности реализации. Аналитик/консультант такой компетенцией не обладает. По некоторым задачам необходимо реорганизовать бизнес-процесс для снижения трудоемкости в разработке. Для этого требуется задать вопросы в правильном ракурсе.
  • Определение структуры метаданных. Данная задача часто поручается либо аналитикам, либо разработчикам. В первом случае, аналитик – не разработчик, а значит правильно спроектировать решение не способен! Во втором случае разработчик будет искать кратчайший путь решения задачи. Он может учесть далеко не все сценарии, а только очевидные для него. Разработчик обычно не работает с данными и не в полной мере осведомлен о протекающих в компании бизнес-процессах.
  • Определение связей между объектами. Данную задачу также поручают аналитикам или разработчикам. Каждый отдельный разработчик и аналитик не в курсе всего пула задач. Следствием этого является доработка тех объектов, которые дорабатывать было нельзя, либо необходим другой способ решения задачи. Выливается это в перекладывании ответственности за неверное решение с одного на другого. В итоге никто не отвечает за возникшие ошибки, а главное никто не предусмотрел, как избежать ошибок.
  • Наполнение системы новыми сценариями. Обычно сценарии тестирования появляются после завершения разработки. Автором сценариев обычно выступает консультант. Это ужасная ошибка!!! Т.к. разработка должна вестись по конкретным сценариям! Необходимо на начальном этапе учесть все сценарии и продумать целостность решения.
  • Обсуждение способа реализации. Обычно этот этап предшествует написанию ТЗ. Участвуют в таких совещаниях все кому не лень. Люди пытаются всеобщими усилиями придумать, как же решать задачу. Т.е. в начале такого обсуждения нет ни одного человека, который знает правильный путь. Это как заблудиться в лесу и всем кричать «ау», вместо того, чтоб взять с собой проводника и GPS трекер. Desing review – это этап, цель которого выяснить, правильно ли разработчик понял постановку задачи, в правильных ли местах в коде он начал доработку. Использовал ли разработчик программный интерфейс. Как видно из описания, ТЗ уже написано! И есть человек, который знает, как правильно решить поставленную задачу!
  • Проверка реализации. В большинстве проектов, которые я видел «со стороны», этот этап либо отсутствует вовсе, либо его поручают разработчикам. Т.е. один разработчик проверяет реализацию у другого разработчика. Что происходит? Каждый разработчик знает только свои задачи. Чтоб проверить задачу, в неё нужно глубоко вникнуть! Т.к. сроки разработки всегда сжаты и уровень разработчиков разный – качество такой проверки носит лишь формальный характер. Многие не соблюдают стандарты разработки, пишут неоптимальный или нечитаемый код, не владеют способами оптимизации запросов и в целом пишут много лишнего кода. Просто поставить галочку в Jire – такой способ проверки подойдёт, однако результата от него не будет!
  • Проверка протокола тестирования. Обычно на этапе тестирования могут появиться новые сценарии (заказчик подкинул, или кто-то из членов команды). Может потребоваться повторное проектирование по новым сценариям. Минусы проектирования консультантами и разработчиками описаны выше.
  • Включение доработки в релиз. Всем знакома ситуация, когда кто-то затер чужие доработки? Это результат того, что сборкой релиза занимаются все кому не лень.

 

Если внимательно прочитать все описанные обязанности архитектора, должно быть понятно, что корректно выполнить эти обязанности может только человек с большим багажом знаний и опыта – архитектор! Качественно заменить архитектора невозможно!

Каждый член команды должен заниматься своей работой:

  • Архитектор – постановкой задач, проверкой результатов и формированием релизов.
  • Аналитик – составлением инструкций, сценариев, сдачей работ заказчику.
  • Консультант – тестированием доработок, поддержка пользователей.
  • Разработчик – выполнением работ по постановкам, утвержденным архитектором.
  • Руководитель проекта – административной работой, мониторингом сроков, управлением бюджетом проекта, переговорами с заказчиком.

 

  1. Чем отличается системный архитектор от функционального архитектора?

 

В последнее время стало модным слово архитектор использовать с префиксами «функциональный» и «системный». Предлагаю разобраться, кто есть кто, а главное нужно ли 2 архитектора?

Итак, функциональный архитектор отвечает за функционал системы, за сценарное наполнение подсистем. Очень часто это НЕ программирующий человек. Он хорошо знает, как решаются различные задачи с помощью типового функционала.

В компетенции такого специалиста входят:

  • Знания обо всех подсистемах внедряемого ПО.
  • Знания о сценарном наполнении объектов.
  • Знания о существующих настройках ПО.
  • Навыки работы с большими объемами данных, способами исправления часто встречающихся ошибок.
  • Навыки сбора и систематизации информации от пользователя.

 

Кто же такой системный архитектор? Это, прежде всего технический специалист и разработчик. В компетенции такого специалиста входят:

  • Знания обо всех подсистемах внедряемого ПО.
  • Знания о сценарном наполнении объектов.
  • Знания о существующих настройках ПО.
  • Навыки работы с большими объемами данных, способами исправления часто встречающихся ошибок.
  • Навыки сбора и систематизации информации от пользователя.
  • Знания об объектах метаданных, правилах их использования.
  • Знания о построении объектов метаданных с точки зрения кода.
  • Знания о способах оптимизации запросов и кода в целом.
  • Знания о стандартах разработки.
  • Знания о серверной архитектуре (опционально).
  • Знания о настройке SQL, администрировании баз (опционально).

 

Как видно из описания, функциональный архитектор отличается от системного архитектора лишь недостатком знаний в области программирования! Если на проекте работают оба специалиста, то возникают следующие недостатки:

  • Постоянный конфликт мнений. Обусловлен он глубокими знаниями архитектуры решения «изнутри». Часто проектируя решения, функциональный архитектор ищет просто кратчайший путь с минимальными доработками. Системный архитектор ищет правильный путь, который верно впишется в концепцию решения, будет оптимально работать по производительности, не нарушит обновляемость системы.
  • Системный архитектор будет работать в полсилы. Обычно это 2 высокооплачиваемых специалиста.
  • Нет единого центра принятия решений. Будет постоянный поиск виноватых, то на стороне постановки задачи, то на стороне реализации.

 

Поэтому если и есть так называемый функциональный архитектор, то он должен подчиняться системному архитектору! Однако можно такому специалисту доверить управление группой аналитиков и консультантов. Такая связка исключает конфликт мнений. Каждый занимается своей задачей и стремится сделать её максимально качественно. Качество – это главный критерий при принятии решений на проекте.

 

  1. Кто главный: РП или архитектор? Кому подчиняется проектная команда?

 

Вечный вопрос: «Кому подчиняется команда?». Не так ли? Можно ли найти в этом вопросе компромисс? Попробуем разобраться.

Для этого разберемся с зонами ответственности РП и архитектора.

Итак, руководитель проекта отвечает за:

  • Коммуникации между проектной командой и заказчиком.
  • Составление план-графика проекта.
  • Составление отчетности по состоянию проекта перед заказчиком.
  • Сбор статусов о готовности задач, как со стороны исполнителя, так и со стороны заказчика.
  • Анализ и предотвращение рисков проекта.
  • Согласование изменений в проекте.
  • Управление бюджетом проекта (опционально).

 

Как видно из описания, руководитель проекта не несет никакой ответственности за качество выполненной работы. Да естественно, ему в первую очередь выскажут претензии за отсутствие качества. НО! Роль РП предусматривает просто принести все претензии команде, узнать, кто и когда их устранит. РП не будет вместе с Вами до ночи программировать или разбирать пользовательские ошибки.

Выше я описал, сферу ответственности архитектора. Как видно, именно архитектор будет основным человеком, который будет заниматься устранением ошибок.

Из этого можно сделать вывод, что по административным вопросам, по коммуникациям и т.д. вся команда подчиняется РП. Но абсолютно недопустимо, когда РП ставит задачу хоть программистам, хоть консультантам без согласования с архитектором.

Из этого можно сделать второй вывод, что по техническим вопросам вся команда подчиняется архитектору. Если архитектор утвердил или отверг тот или иной вариант решения задачи, то никто из команды не вправе менять решение архитектора. Даже всемогущий руководитель проекта не имеет на это права. Т.к. я не знаю ни одного РП, который способен заказчику прямо сообщить: «Это я сказал архитектору сделать так (сроки поджимали, или денег нет в проекте на это), и это из-за меня возникла такая проблема».

Даже если предположить, что руководитель проекта на это способен, то абсолютно неверно принимать решение, из-за которого возникнет проблема. Именно архитектор отвечает за то, чтоб никаких проблем не возникало.

Задача грамотного и опытного руководителя проекта выяснить, сколько ресурсов требуется на решение затянувшейся задачи, узнать аргументы для заказчика и донести всю эту информацию до заказчика. В таких ситуациях абсолютно оправдано взять с собой архитектора на совещание, чтоб он пояснил заказчику техническим языком, почему так, а не иначе.

Специальные предложения

Лучшие комментарии
43. Yashazz 3246 01.07.20 20:04 Сейчас в теме
Трепология ни о чём. Пустое умствование. И знаете почему? Потому что а) использующие архитекторов имеют своё видение, оно у них как откровение свыше, альфа и омега, пуп их знания о проекте, и переубеждать бесполезно; б) не использующие архитекторов свято убеждены, что без них всегда жили и дальше прокатит; в) ничто не влияет на процесс внедрения и эксплуатации системы меньше, чем наличие/отсутствие и качество архитектора на проекте.
Grania; biimmap; +2 Ответить
44. sapervodichka 3820 02.07.20 00:05 Сейчас в теме
Мне понравилась данная статья, т.к. в моей жизни реально происходит то, о чём пишет автор. Приходится общие концепции в разработке контролировать у групп программистов. Обидно только, что оплату и полномочия архитектора не каждый РП выделяет на своём проекте (т.к. придётся премией делиться к архитектором) и часто время за концепт и целостность продукта оплачивается по той же ставке, что и разработка отчета или документа. Короче фигня такая *)
Остальные комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. barelpro 1161 29.06.20 23:30 Сейчас в теме
Немного не понятно как быть на крупных проектах? В одно лицо уточнить задачи, придумать решение, поставить задачу, проверить реализацию, собрать релиз - бутылочное горлышко. Все в итоге будут работать в пол силы или имитировать бурную деятельность пока бедолага рвёт базис на британский флаг! Мой опыт подсказывает иерархию архитекторов по направлениям, с одним корневым. Под каждым архитектором три- пять разрабов.

А в целом разумная статья!
2. shmalevoz 201 30.06.20 08:34 Сейчас в теме
(1) Просто проект имхо должен начинаться с создания архитектерного каркаса - интерфейсов, заготовок объектов, ... На это тратится до месяца, а дальше можно этот каркас наполнять смыслом в порядке приоритетов. Тогда задачи ставятся на 70% комментариями к методам, там должен быть контракт метода. Заодно можно и поставить требование перед кодом покрыть решаемое тестами. В код ревью и тем паче сборке очень неплохо помогают средства автоматизации. Архитектор имхо лучше когда один, если есть деление на группы, то там "старшие" групп. Но не архитекторы.
Спасибо за статью.
barelpro; +1 Ответить
8. barelpro 1161 30.06.20 12:07 Сейчас в теме
(2)
Тогда задачи ставятся на 70% комментариями к методам, там должен быть контракт метода


Интересно!
А где про этот метод можно почитать подробнее?
9. shmalevoz 201 30.06.20 12:21 Сейчас в теме
(8) Как раз на главной странице странице ссылка на книгу
Не спеша эффективно и правильно
там есть про это в Базовые методы проектирования, в частности про Черный ящик и особенно Первородство спецификации
а аннотации начинают писаться если обязать всех использовать шаблоны, в которых есть заготовки комментариев. ну и просто не пропускать методы без описания. через пару месяцев приходит привыкание =)
10. barelpro 1161 30.06.20 12:24 Сейчас в теме
(9) а, ок, спасибо! Как раз эту статью отложил для чтения на выходные )))
3. awk 714 30.06.20 08:55 Сейчас в теме
Статья - отличная. Читается легко, почти нет воды. Одна из немногих, которую читал не по диагонали.

Однако возник вопрос:

Как

Наполнение системы новыми сценариями. Обычно сценарии тестирования появляются после завершения разработки. Автором сценариев обычно выступает консультант. Это ужасная ошибка!!! Т.к. разработка должна вестись по конкретным сценариям! Необходимо на начальном этапе учесть все сценарии и продумать целостность решения.


может сочетаться с

Каждый член команды должен заниматься своей работой:

Архитектор – постановкой задач, проверкой результатов и формированием релизов.
Аналитик – составлением инструкций, сценариев, сдачей работ заказчику.


И складывается впечатление, что архитектор - это сверхчеловек, что очень сомнительно, для людей не верящих в Деда Мороза.
for_sale; ivanov660; a.abelentsev; Aluvika4; +4 1 Ответить
5. biimmap 47 30.06.20 09:51 Сейчас в теме
(3) Имелось ввиду, что консультант не должен быть единственным автором сценариев. Их необходимо согласовывать с архитектором и бизнес-заказчиком. Любое требование бизнеса должно переводиться в сценарии.

Что касается Деда Мороза - это как верить в Бога... Каждый сам выбирает верить ему или нет! Однако на своих проектах я и есть тот самый Дед Мороз))

Спасибо что внимательно читали.
6. awk 714 30.06.20 10:00 Сейчас в теме
(5) Боюсь, что если добавить роль "Тестировщика" и "Ведущего тестировщика", то сценарии тестирования/использования уйдут на него и роль Архитектора не будет выглядеть как роль "Супермена". Я правда только на одном предприятии такую роль видел, а точнее целый отдел.

А вообще про архитектора очень хорошо написано в книге "Унифицированный процесс разработки" https://krupoderovakr.files.wordpress.com/2014/02/d0b0-d18fd0bad0bed0b1d181d0bed0bd-d0b3-d0b1d183d187-d0b4d0b6-d180d0b0d0bcd0b1d0be-d183d0bdd0b8d184d0b8d186d0b8d180d0bed0b2d0b0d0bd.pdf
7. biimmap 47 30.06.20 10:05 Сейчас в теме
(6) Речь в согласовании, а не написании! Пишет в любом случае аналитик/консультант, можно тестировщик, если такой есть выделенный. Я за всё время видел только 2-х человек, которые могут найти дырки в куске масла (не сыра! а именно масла). Это редкая компетенция.
4. AlbinaAAA 862 30.06.20 08:59 Сейчас в теме
Очень полезная статья, спасибо за труд. Жду следующие статьи!
11. rossoxa 139 30.06.20 14:07 Сейчас в теме
Отличная статья. Очень точно и грамотно. Спасибо
12. xrrg 214 30.06.20 22:49 Сейчас в теме
Надеюсь, мы скоро дождёмся статьи про истинно верное написание проектной документации.
14. biimmap 47 30.06.20 23:19 Сейчас в теме
(12)Вы знаете именно этой темы в запланированных 8-ми статьях нет. Причина тому - некачественные разработки довольно неплохо документируют)))
40. xrrg 214 01.07.20 17:40 Сейчас в теме
(14) Экстравагантное мнение. То есть чем меньше документации (желательно чтоб на рулоне туалетной бумаги была написана от руки), тем лучше сделан проект? Есть ГОСТ на это дело. Вижу слово ТЗ, а слова ТП не вижу. Вы имеете опыт написания подобного документа? (Подсказка: это прямая обязанность архитектора)
41. biimmap 47 01.07.20 17:46 Сейчас в теме
(40) Вы неверно прочитали мой ответ. Немного расшифрую: Цель статей - поднять качество разработки в крупных проектах. Ибо количество теплокодеров просто зашкаливает. При этом на всех проектах документации хоть дома из неё строй. Поэтому не вижу смысла описывать как должны проекты документироваться, т.к. здесь проблем на проектах не так много. Сначала надо разработку вести правильно! Соблюдать стандарты и т.д. Мне приходилось делать абсолютно всё в т.ч. в одно лицо. Ответ же связан не с моим опытом, а с направленностью всего цикла статей.
42. xrrg 214 01.07.20 17:51 Сейчас в теме
(41) у вас есть опыт подготовки проектной документации?
13. 1СERP 2020 30.06.20 23:17 Сейчас в теме
Все понял, кроме одного. С чего это такой ограниченный функционал у РП?
Управление качеством - ключевая задача РП. Как он этого добьётся - отдельная задача. Сам - эксперт. Привлекает эксперта (Архитектора). Ещё какие-то варианты...
В том варианте, который описан, РП - это, скорее, администратор проекта.
Мы так пробовали - не сработало.
15. biimmap 47 30.06.20 23:21 Сейчас в теме
(13) Я ждал этого вопроса... Отвечу кратко: РП - обычно человек с чек-листом, которому некогда вникать в суть. Ему надо просто знать когда. Архитектор - обратная сторона монеты. Просто каждый должен быть на своем месте. Орел и решка не могут быть с одной стороны монеты!
16. puzakov 01.07.20 06:41 Сейчас в теме
Статья слишком абстрактная. Автор, попробуй расписать:
- какие цели у архитектора и разработки архитектуры
- что является показателями хорошей и плохой работы архитектора
21. biimmap 47 01.07.20 09:55 Сейчас в теме
(16) Есть ощущение, что задачи архитектора это оно и есть.
А вот про показатели хорошей и плохой работы действительно стоит добавить...
17. for_sale 854 01.07.20 08:27 Сейчас в теме
Архитектор (в нормальном виде) – это самый грамотный и самый опытный.

Калёным железом надо выжигать из архитектора, руководства и остальной команды эту уверенность. Всегда должно быть место аргументированной дискуссии. А то приходят на проект такие вот архитекторы, понасочиняют архитектур, а потом все попытки этого остолопа убедить в чём-то разбиваются о "я архитектор, я так вижу, я самый грамотный и опытный" вместо аргументированного обоснования, почему так лучше всего.
mikl79; da.buraev; Grania; a.abelentsev; +4 1 Ответить
31. biimmap 47 01.07.20 14:30 Сейчас в теме
(17) Что вижу в этом посте:
1. Вам не дают архитекторы принимать самостоятельные решения, а убедить их аргументами наверно не получается.
2. Аргументированная дискуссия лишь в том случае, если аргументы направлены на улучшение решения. Могу только предположить, что более опытный архитектор отклоняет аргументы, т.к. они направлены на упрощение разработки, а не на улучшение качества и целостности системы.
3. Вижу прямое оскорбление в адрес всех архитекторов. Автор комментария их считает остолопами.

Я здесь не вижу ни одного аргумента, почему архитектор не является самым грамотным на проекте.

К примеру на одном из моих проектов тим лид пыталась меня всё время склонить в сторону более быстрых и некачественных проектов. Ессно она получала от меня отказ. И якобы я был плохой. Но от тех решений, которые она продавливала плевались и тестировщики и заказчики!

Именно поэтому данный комментарий я склонен игнорировать полностью.

Предлагаю Вам взять на себя ответственность за весь проект и стать архитектором. Тогда Вам никто не будет указывать как делать. Это будет полностью сфера Вашей ответственности.

Здесь от меня нет перехода на личности. А от Вас есть оскорбления и эмоции.
33. for_sale 854 01.07.20 14:50 Сейчас в теме
(31)
Мдаааа... всё ещё сложнее, чем я думал. То есть человек не в пылу задетых чувств переходит на личности - он даже в принципе не способен отличить переход на личности от аргументированной дискуссии. Спрятался за щитом "я архитектор, я самый грамотный и умный, не лезьте ко мне, любите меня таким, какой я есть". И потратил час времени на то, чтобы в очередной раз обсудить высказавшего, а не высказанное, причём, залив это личными эмоциями.

Я потому и писал комменты и влепил вашей поделке минус - именно, чтобы вот такие "архитекторы" не превратились в пандемию.
da.buraev; a.abelentsev; Grania; +3 Ответить
34. biimmap 47 01.07.20 14:52 Сейчас в теме
(33) Коллега, в моё посте нет эмоций. Ваш наполнен ими и оскорблениями. Спасибо за "участие".
46. da.buraev 02.07.20 02:18 Сейчас в теме
18. for_sale 854 01.07.20 08:34 Сейчас в теме
Выяснение требований. Часто эту задачу поручают аналитикам или консультантам.

И правильно делают. Архитектор - это технический специалист. Он может выяснять требования только если на той стороне сидит другой технический специалист (в идеале - тоже архитектор), и они могут говорить на одном языке. О чём может говорить архитектор с финансовым директором или с пенсионеркой-бухгалтером? Ну нам вот надо такую кнопку, чтобы нажать - и всё работало. Архитектор вообще может не знать (и не должен знать!) прикладную область, это атавизм сферы 1С, когда архитектор - это и программист, и бухгалтер, и кадровик, и финансист. В какой-нибудь джаве архитектор - это архитектор, он сегодня автоматизирует банк, завтра - космодром, послезавтра - интернет-казино, он не может и не обязан разбираться во всех этих сферах.

Поэтому да, если на той стороне не такой же архитектор, а абстрактный заказчик, то требования должен выяснять именно аналитик. То есть тот, кто хотя бы в общих чертах сможет понять, чё ему надо, этому заказчику. И потом уже рассказать архитектору всю будущую систему, как её видит специалист в прикладной области.

Простой пример. Если тёте-бухгалтеру нужна большая красная кнопка, чтобы всё делала для надзорных органов, то что не разбирающийся в прикладной области архитектор сможет ей напридумывать? А аналитик сможет расшифровать для архитектора, что кнопка должна считать себестоимость, фин.результат, закрывать месяц и т.д. и т.п.

Да, в сфере 1С архитектор может быть сразу и аналитиком. Но это, повторюсь, атавизм и нарушает принцип разделения труда. Такому специалисту всё сложнее будет поддерживать свои знания актуальными во всех сферах, стоить он будет непомерно дорого и т.п.
Grania; a.abelentsev; +2 1 Ответить
32. biimmap 47 01.07.20 14:46 Сейчас в теме
(18) Что в этом посте написано:
1. Архитектор может выяснить детали только у технического специалиста.
2. Архитектор не должен знать предметную область.
3. Аналитик может выяснить требования в общих чертах и передать архитектору.
4. Архитектору со знанием предметной области будет сложно поддерживать свои знания актуальными во всех сферах.

Отвечу на каждый пункт:
1. Здесь нет ни одного аргумента, почему вдруг архитектор не может выяснять потребности у заказчика? Скорей всего автор опирается на следующий пункт (нет знаний в предметной области).
2. Моя статья в п. 5 описывает кто такой системный архитектор. Мне крайне тяжело в среде 1С (а именно об этом моя статья) представить архитектора ЕРП, который не знает производство и ни разу не был в цеху. Также и здесь, если архитектор не знает предметную область - это не архитектор, а всего лишь ведущий разработчик! Вы описываете ситуацию, когда на проекте нет архитектора и его обязанности исполняет ведущий разработчик! Это очень плачевная ситуация. Я в свое статье рассказываю, что так быть не должно ни в коем случае!
3. В п.4 своей статьи я описал недостатки того, что аналитик выясняет суть задачи. Когда аналитик дойдёт до архитектора, то получится испорченный телефон, который уже забыл половину разговора с заказчиком (таково устройство памяти). Да действительно по некоторым отдельным задачам архитектор может и должен поручать аналитику такую работу. Но в этом случае аналитик получает инструкции от архитектора, какие вопросы требуется выяснить. И потом в несколько итераций аналитик приносит информацию архитектору, пока не будут даны развернутые ответы на поставленные архитектором вопросы.
4. Архитектор не может и не должен работать в разных областях. Я лично (тут на свою личность перейду) работаю в сфере зарплаты. Другие сферы я не знаю и даже знать не хочу. Конечно невозможно быть архитектором в нескольких предметных областях. Это крайне сложно. Также в помощь архитектору на проекте есть МЕТОДОЛОГ. Но аналитик - это не методолог. Если говорить об одной задаче, то да аналитик может и должен помочь. Но моя статья написана про проект в целом! И здесь аналитик не может проектировать архитектуру всего проекта, и даже 5 аналитиков на это не способны. они должны подчиняться одному центру принятия решений!

Здесь тоже не вижу аргументов по моей статье. Здесь описан Ваш опыт, и к сожалению - он неправильный! Так быть не должно! Именно для этого написана моя статья.
35. for_sale 854 01.07.20 15:48 Сейчас в теме
(32)
1. Здесь нет ни одного аргумента, почему вдруг архитектор не может выяснять потребности у заказчика?

Если бы вы читали полностью и уважали чужое мнение, а не эмоционировали на любое несогласие с вашим самолюбованием, вы бы увидели там целый абзац разъяснений, почему.


(32)
Мне крайне тяжело в среде 1С (а именно об этом моя статья) представить архитектора ЕРП, который не знает производство и ни разу не был в цеху.

То, что вам тяжело, совсем не значит, что вы совершенно правы. Именно об этом я и писал - что сфера 1С всё ещё полна вот такими атавизмами и такими "архитекторами" (обязательно в кавычках!), которые уверены, что только так правильно и что они - самые грамотные. Именно об этом я и писал, что у вас архитектор сросся с аналитиком и РПшником и даже не хочет задумываться о том. что может быть что-то делает неправильно. Даже не неправильно, до этого вообще далеко, но даже не хочет задумываться о том, чтобы вообще проанализировать происходящее, поискать какие-то альтернативы. Нет, такой "архитектор" - он самый умный и самый грамотный, наместник бога на земле, не спорьте с ним!

И из вот этого подхода, конечно же, неминуемо должно было явиться вот это:

(32)
Архитектор не может и не должен работать в разных областях. Я лично (тут на свою личность перейду) работаю в сфере зарплаты.


Теперь архитектор - он вообще уже не архитектор, оказывается, а скрещенный с кадровиком программист)) Типичная история в сфере 1С, это понятно. Но когда эта типичная история ещё и ходит по форумам и на полном серьёзе пишет статьи, где заявляет свои аксиомы, что так правильно и так и должно быть - это уже совсем странно.

И что мы имеем в результате? Архитектор - это (в вашем случае) кадровик-аналитик-программист, который способен (и должен!!!) уметь только придумывать регистры зарплатного учёта!

(32)
Когда аналитик дойдёт до архитектора, то получится испорченный телефон, который уже забыл половину разговора с заказчиком

Ну а за такие несуразицы я вашу статью чушью и назвал)) В какой-то момент вы просто срываетесь в какой-то горячечный бред. "Забыл половину разговора". И мы это обсуждаем всерьёз? Или вы за полным недостатком аргументов в этот детский сад скатились? Если, как говорилось в анекдоте, "он идиот и забывает, то пусть записывает, как это делаю я")) Жесть. Уровень аргументов просто зашкаливает за плинтус. "Господа, так как аналитики у нас с короткой памятью, то пусть пишут инструкции, а вместо них работают архитекторы!"))

Ладно, я уже понял, что, скорее всего, вы ничего не поняли и не поймёте, так бывает всегда, когда человек себя объявляет "самым грамотным и умным" и отказывается обучаться. Но оставлю здесь это для тех, кто, может, зачем-то и правда придёт в эту статью за осмыслением роли архитектора.

Итак, сравним кейсы вашего суперархитектора, рядом с которым бегают ничего не понимающие программисты и постоянно всё забывающие аналитики, которые пишут инструкции, и ту ситуацию, которую описывал я.

Суперархитектор: свойства
Стоит очень дорого, потому что знает сразу и "архитектурирование", и прикладную область.
Сутками обучается, чтобы поддерживать актуальными знания во всех областях. Либо просто скачет по верхам (но стоит всё равно дорого!). Либо однажды актуализировался, и теперь считает себя самым умным, а время и новая информация летит мимо него (но стоит всё равно очень дорого!).
Работал только на одном типе проектов, досконально знает только одну сторону платформы.

Суперархитектор в среде обитания
Начинаем проект. Ищем архитектора именно в этой области, потому что он жыш обязан знать прикладную область! Кое-как нашли (товар-то штучный и дорогой!), внесли его непомерную ЗП в себестоимость и цену. Этот полубог общается с заказчиком, со всеми заинтересованными ролями, впитывает в себя потребности бизнеса (а он все его стороны знает, не забываем!), затем придумывает тоннель, в конце которого эти потребности реализовываются, и разрабатывает архитектуру вплоть до последнего регистра (он же и в программировании умнее всех!). Через полгода или год проект начинает реализовываться. При этом к нему приставляют охрану из пяти телохранителей, оборачивают в три слоя поролона и хранят в закрытом бункере, потому что если с ним что-то случится или он уйдёт - проект умрёт.

Теперь попробуем альтернативный вариант, где каждый занимается своим делом

Аналитик: свойства
Знает только прикладную область и немного - язык технарей.
Стоит дорого, но дешевле суперархитектора раза в два-три.
Не обучается сутками, но всё равно поддерживает гораздо более узкую сферу знаний актуальной.

Архитектор: свойства
Знает только техническую сторону платформы на уровне крутого специалиста
Также стоит дорого и также дешевле суперархитектора в два-три раза
Также без проблем поддерживает узкую область знаний актуальной. Более того, так как он работал на разных проектах, имеет больше гибкости в подходе и знает разные стороны технической части, что иногда позволяет приходить к нестандартным, но эффективным решениям.

Проект
Начинаем проект. Ищем аналитика, который знает только прикладную область и умеет её доносить технарям. Он общается с заказчиком и, разговаривая на одном языке, понимает, что нужно бизнесу в конце тоннеля. Аналитик пишет функциональные требования о том, что нужно, чтобы получить результат, чего хочет заказчик. ФТ оперирует понятиями высокого уровня - "список сотрудников", "передаёт заказ в служу доставки", "руководитель формирует отчёт" и т.п. Первый этап завершён, на нём работал только РП и аналитик, не требовалось привлечения и простоя других кадров. На этом роль анатилика заканчивается, ресурс высвобождается, он может участвовать в других проектах. При этом, если аналитик выходит из проекта где-то до этой черты, то заменить нужно только аналитика и затраты только в работе аналитика.

РП оценивает проект, нужные ресурсы, нужное время. Теперь он ищет архитектора, который знает техническую часть. Это гораздо проще, чем найти суперархитектора. Архитектор в свою очередь на основании ФТ изобретает архитектуру решения и пишет ТЗ. ТЗ оперирует понятиями прикладного технического уровня - "регистр сведений Список сотрудников", "по нажатию на кнопку... запускает бизнес-процесс...", "команда в разделе... формирует отчёт..., видна пользователю с ролью...". Если он выходит из проекта где-то до этой черты, то заменить нужно только архитектора, работа аналитика уже выполнена, её не нужно переделывать, затраты - только в работе архитектора.

Выводы, какой подход лучше, даже не буду писать, пусть каждый сам сделает их для себя.
a.abelentsev; gavlexx; Grania; +3 Ответить
19. for_sale 854 01.07.20 09:01 Сейчас в теме
Аналитик – составлением инструкций, сценариев, сдачей работ заказчику.

Что за чушь??? Вы название хотя бы прочитайте!
"Аналитик"! Чем должен заниматься "Аналитик"? Само название происходит от слова Анализ! Да, он может всем вышеописанным заниматься теоретически (и постоянно занимается практически), но просто потому, что в этой сфере всё ещё дикий запад и никто почему-то до сих пор не может натянуть правила разработки, которые десятилетиями используются в других сферах, на эту.

Аналитик должен прежде всего АНАЛИЗИРОВАТЬ. Это - первая линия обороны, которая и должна общаться с заказчиком (а не архитектор!), выяснять, что у них есть, что им нужно и АНАЛИЗИРОВАТЬ, как это все превратить в полезный конечный результат. И дальше уже результаты своего АНАЛИЗА предоставить архитектору для технической реализации. Это как раз и есть самый грамотный, который должен с языка заказчика на язык архитектора перевести. От него должна зависеть в целом судьба проекта. Если заказчик говорит при сдаче проекта - а мы не это хотели! - то это как раз вина аналитика.

И на этом (АНАЛИЗЕ) его роль завершается, дальше уже начинается королевская печать с орехами. Инструкции писать - чушь! Инструкции пусть пишет консультант (это по идее не такой продвинутый специалист, и менее дорогостоящий, к тому же более приближённый по знаниям к конечному пользователю - операторам, бухгалтерам и т.п.) Аналитик - это стратег, он НЕ должен тратить время на описание кнопочек.

А вы просто рассказали и "утвердили", как оно сейчас в сфере 1С есть. Где аналитики - это просто консультанты в профиль, которые за три копейки пишут инструкции пользователям и понятия не имеют, как из требований заказчика сделать конечный результат. Где "я проработал оператором 1С полгода, больше ничего не умею - пойду в аналитики!". Вы просто перепутали архитектора и аналитика, назначив архитектору бОльшую часть функций аналитика.

Аналитик - это стратегия и концепция проекта. Дальше уже по этой стратегии и концепции архитектор придумывает техническую сторону, а РП - прогнозирует стоимость и сроки. Когда в нашей многострадальной сфере это поймут, количество горделивых рассказов про "истории ещё одного провалившегося проекта" будет гораздо меньше.
sapervodichka; ivanov660; Grania; a.abelentsev; +4 1 Ответить
22. biimmap 47 01.07.20 10:10 Сейчас в теме
(19)
чушь??? Вы название хотя бы прочитайте!
"Аналитик"! Чем должен

К сожалению, чушь пишите Вы! И данная статья направлена ровно на таких как Вы.
Я часто в своей практике встречаю проекты, в которых либо нет архитектора вообще, либо архитектор только функциональный. И никто не контролирует процесс разработки.

С этим связаны например такие постановки (моей подруге на днях поставили задачу):
Необходимо создать отчет для сверки соответствия плановых начислений тем, что предусмотрены по штатному расписанию. Дальше пишут: Данные необходимо собирать по документам "Кадровый перевод" и "Изменение оплаты труда".

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

Так вот архитектор таких ошибок глупых не допускает!

Поэтому Ваше мнение проигнорирую. Аргументы у Вас слабые. Я основываюсь на своём опыте и на достижении результата, а не на названиях.
23. ivanov660 2132 01.07.20 11:02 Сейчас в теме
(22)Каждый должен заниматься своими обязанностями.
У вас идет перекос обязанностей в сторону архитектора. Как в поговорке - и жнец и на дуде игрец.
Архитектор должен держать в голове укрупненный каркас и должен контроллировать процесс сборки этой констркуции.
Далее в зависимости от процесса разработки существуют различные наборы команд, в которых различные роли и обязанности.
В итоге - у вас есть кейс, он рабочий в определенных условиях, но не единственный.
sapervodichka; for_sale; +2 Ответить
26. biimmap 47 01.07.20 13:38 Сейчас в теме
(23)
Архитектор должен держать в голове укрупненный каркас и должен контроллировать процесс сборки этой констркуции.
Я согласен с Вашей формулировкой и не вижу отклонений в своём тексте. Архитектор должен участвовать во всех ключевых процессах и контролировать их. Последнее слово по техническим решениям за архитектором, а не за РП или аналитиком не дай бог. И главное чтоб он вообще был! Вот об этом статья!
24. a.abelentsev 119 01.07.20 11:42 Сейчас в теме
28. biimmap 47 01.07.20 13:43 Сейчас в теме
(24) приветствую. даже интересно что ты имел ввиду. Для публики: Артур был мои руководителем, когда я приехал в Москву. Работал я просто программистом по ТЗ от аналитика.
25. for_sale 854 01.07.20 11:50 Сейчас в теме
(22) Ваш комментарий многое объясняет в вашей статье. Сразу становится понятно, откуда эти тезисы "архитектор самый умный, никто с ним не должен спорить")) Переход на личности и обсуждение высказавшего, а не высказываемого, "я самый умный, не спорьте со мной" - вот такие у нас архитекторы.

Вопросов больше нет, статье - жирный минус. По таким материалам потом и получим новое поколение таких вот "архитекторов".
sapervodichka; a.abelentsev; Grania; +3 1 Ответить
27. biimmap 47 01.07.20 13:41 Сейчас в теме
(25) не вижу в своем комментарии перехода на личности... Я знаю, что будут те кто не согласны со мной. И готов к этому. Но называть без аргументов (просто основываясь на своих привычках) статью чушью - мне кажется это неадекватным. Да и кто заставляет читать? можно пройти мимо...
29. for_sale 854 01.07.20 13:46 Сейчас в теме
(27) Я вам воз и тележку аргументов привёл. Но вы же решили просто "игнорировать мнения", отличные от вашего.
sapervodichka; +1 Ответить
30. biimmap 47 01.07.20 13:48 Сейчас в теме
(29) хорошо, я отвечу подробно с примерами на каждый ваш аргумент. полчаса времени требуется.
37. barelpro 1161 01.07.20 16:04 Сейчас в теме
(19)

Для начала надо уточнить, что в 1С-проектах используются системные аналитики. Бизнес аналитики как правило являются заказчиками для системных аналитиков. Системный аналитик - это файервол между бизнесом и командой разработчиков. Берёт на себя все первичные разговоры с бизнесом, проверяет адекватность и реалистичность, систематизирует, отсеивает шлак, и выдает команде в краткой содержательной форме основной смысл хотелок. Далее после того как РП проверил эти хотелки на входимость в рамки проекта, можно сделать второй подход к бизнесу с уточняющими вопросами. Вот тут уже могут быть варианты, кто пойдет - аналитик или архитектор. О правилах ролевой игры проектная команда договаривается внутри себя заранее. Тут главное слово скорее за РП.
Многое зависит от кадровой составляющей - если достался сильный аналитик и никакой архитектор (который максимум тянет на релиз менеджера) - это беда! Если наоборот - в принципе архитектор конечно вытянет две функции, но есть риск что поплывут либо сроки либо качество.
Это касается первой фазы проекта - постановка, проектирование, моделирование.
На второй фазе (разработка и внедрение), когда основные хотелки уже выявлены, аналитик нужен разве что для проверки уточненных требований на соответствие скопу проекта. Его функции плавно перетекают в то, о чем написано в статье. Либо аналитик вообще уходит.
38. gavlexx 37 01.07.20 17:22 Сейчас в теме
Архитектор должен выяснять у Заказчика требования? При разделении труда - точно нет. Только если он же - и выясняет, и строит архитектуру и программирует.
Но цикл статей же не о "на-все-руки-мастеров-1С", верно? :)
Grania; for_sale; +2 Ответить
39. biimmap 47 01.07.20 17:30 Сейчас в теме
(38) Вечер добрый. Почему люди размышляют ОДНОЙ ЕДИНСТВЕННОЙ ЗАДАЧЕЙ? Статья написана про проект в целом. Проект состоит из множества задач. И всё это множество между собой связано! И только в этом ракурсе необходимо воспринимать написанное! Я написал про КОНЦЕПЦИЮ, т.е. АРХИТЕКТУРУ.
Могу сотнями приводить примеры, где Аналитик, так восхваляемый некоторыми, приносил от Заказчика вообще не то. Просто не понял смысл задачи. В таких случаях возникает сомнение в правдивости принесенной информации. Выясняю сам - получаю совсем другие ответы.
43. Yashazz 3246 01.07.20 20:04 Сейчас в теме
Трепология ни о чём. Пустое умствование. И знаете почему? Потому что а) использующие архитекторов имеют своё видение, оно у них как откровение свыше, альфа и омега, пуп их знания о проекте, и переубеждать бесполезно; б) не использующие архитекторов свято убеждены, что без них всегда жили и дальше прокатит; в) ничто не влияет на процесс внедрения и эксплуатации системы меньше, чем наличие/отсутствие и качество архитектора на проекте.
Grania; biimmap; +2 Ответить
44. sapervodichka 3820 02.07.20 00:05 Сейчас в теме
Мне понравилась данная статья, т.к. в моей жизни реально происходит то, о чём пишет автор. Приходится общие концепции в разработке контролировать у групп программистов. Обидно только, что оплату и полномочия архитектора не каждый РП выделяет на своём проекте (т.к. придётся премией делиться к архитектором) и часто время за концепт и целостность продукта оплачивается по той же ставке, что и разработка отчета или документа. Короче фигня такая *)
45. biimmap 47 02.07.20 00:45 Сейчас в теме
(44) Спасибо тебе добрый человек за твой комментарий)))
Оставьте свое сообщение

См. также

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Многие руководители предприятий не обладают полной картиной происходящего в собственных производственных подразделениях. Они знакомы с организационной структурой, направлениями деятельности, общими экономическими показателями. Если по результату получилась прибыль, то наступает уверенность успеха. Но есть ли на рынке предприятия, которые длительное время удерживаются в "слепом" режиме управления?

23.02.2017    27003    0    Gavrik    10    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    5694    0    roman72    0    

Модернизация КА 2.4 под маркетинговую компанию. Часть 1

Управление взаимоотношениями с клиентами (СRM) Техническое задание v8 КА2 Россия УУ Бесплатно (free)

Выполнил для компании, которая занимается маркетингом и продвижением продуктов, проектирование и модификацию конфигурации КА 2.4 и справочника «Проекты». Теперь в конфигурации «Проекты» имеют особенную роль и на основании выполненной доработки руководство компании принимает решения по продолжению, закрытию или продвижению проекта/ов, поиск путей решения возникающих вопросов. При необходимости доработку можно реализовать под ERP конфигурацию. Архитектура решения выполнена «рядом» с основной конфигурацией. В настоящее время конфигурация поддерживается, модификация ведется в актуальной версии КА 2.4.10 на платформе 8.3.14.1630.

29.10.2019    5735    0    BraunAlex    1    

Мастер-класс СППР

Управление проектом СППР Бесплатно (free)

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    10507    0    SergeyN    6    

ГОСТ 34.602-89. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ Промо

Техническое задание Россия Бесплатно (free)

Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее - ТЗ на АС). Дата введения с 01.01.1990г

29.06.2005    36331    0    support    11    

Impact mapping: чем он может быть вам полезен

Техническое задание Бесплатно (free)

Привет, коллеги! Сегодня хочу поговорить про один из инструментов Владельца продукта - Impact mapping (карта влияния). Чем он хорош и почему его стоит использовать.

26.07.2019    6129    0    slozhenikin_com    14    

Как проектировать отчетность

Техническое задание Управление проектом Управленческие v8 УУ Бесплатно (free)

Эта статья написана по итогам мастер-класса для руководителей проектов и аналитиков, в рамках перехода на продуктовый подход к разработке. В ней мы постарались ответить на вопрос: "Как снизить риск потери доверия к данным информационной системы со стороны топ-менеджмента, грамотно выстроив процесс проектирования и разработки отчетности?"

16.10.2018    9096    0    weissfeuer    2    

Проектирование архитектуры и модификация программных продуктов как технология в сложных проектах системной интеграции и автоматизации на базе 1С: СППР

Управление проектом Интеграция СППР v8 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Как сделать проектирование функциональной архитектуры ПО технологией. Цель - устранить ряд типовых проблем на сложных проектах. Как использовать для решения этих задач 1С система проектирования прикладных решений (СППР). Статья полезна для директоров франчайзи, системных интеграторов, руководителей проектов, архитекторов и консультантов.

03.10.2018    15772    0    roman72    19    

Есть 2 подхода к внедрению информационных систем. На примере 1С УПП 8 Промо

Управление проектом Техническое задание v8 УПП1 Россия Бесплатно (free)

С детальным ТЗ? Или без серьезного ТЗ? Какой лучше? И где успех более вероятен?

26.01.2012    55617    0        54    

На чьей стороне мячик? Алгоритм определения исполнителя задачи

Техническое задание Управление бизнес-процессами (BPM) Бесплатно (free)

Я считаю, что мало кому удалось избежать ситуации, когда его назначали исполнителем работы, мягко скажем, не его уровня. На мой взгляд, такое особенно часто встречается среди технических специалистов. Причем, в случае возражения, обычным аргументом противоположной стороны является: "Нам так раньше всегда делали!". Эта публикация является попыткой описать формализовано процесс определения исполнителя с точки зрения логики. Посвящается тем, кто, будучи невежественным в вопросе, смеет указывать, кому его решать. А также тем, кто это терпит.

14.08.2018    7233    0    itriot11    42    

Первый шаг к успешному проекту автоматизации

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Россия Бесплатно (free)

Всем нам хочется, чтобы проект по автоматизации предприятия был успешным? Чтобы поставленные цели были достигнуты в срок и затраты не превысили запланированных? В нашей статье мы расскажем, каким, по нашему мнению, должен быть первый шаг к успешному проекту.

30.03.2018    10117    0    Aprsoft    1    

Должностная инструкция специалиста по 1С

Техническое задание Бесплатно (free)

Описание функциональных обязанностей для трёх категорий специалистов 1С: Администратор платформы, Программист, Администратор конфигурации (Методист).

14.12.2017    25217    0    Vikki-di    20    

Внедрение МСФО: план-график выполнения проекта по автоматизации МСФО

Техническое задание Управление проектом МСФО (GAAP) МСФО (GAAP) БУ Бесплатно (free)

В данной статье будут детально рассмотрены задачи, которые предстоит выполнить в процессе запуска проекта автоматизированной подготовки отчетности МСФО

23.10.2017    9989    0    user743750    0    

Систематизация опыта подготовки технического задания

Техническое задание 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Решил «закинуть» на портал свою статью пяти-шестилетней давности. Статья писалась для внутреннего употребления в нашей компании – обобщил и систематизировал свой опыт. Думаю, кому-то она будет полезной. В процессе подготовки статьи немного отредактировал первоначальный вариант.

26.04.2017    23965    0    Soliton    33    

Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С

Техническое задание Управление проектом Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика Бухгалтерский учет Управленческий учет (прочее) Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика v8 Россия УУ Бесплатно (free)

Это схема и обоснование концепции системы АУБ (Автоматизация Управления Бизнесом, авторская разработка) для автоматизации многопрофильного холдинга на платформе 1С. Система изначально проектировалась для многопрофильного холдинга, что определило особенность ее концепции - три уровня автоматизации. Система АУБ не является готовым решением, это определенная концепция (видение, подход) к автоматизации управленческого учета и расширяемый базис наработок реализованных в этой концепции. В конкретном проекте автоматизации, с учетом специфики управления предприятием, делается индивидуальная «функциональная сборка» с использованием готовых, существенно модифицируемых и заново разрабатываемых подсистем. Таким образом, концепция и расширяемый базис наработок системы АУБ, представляют своего рода конструктор, из которого компонуется решение в конкретном проекте, при этом заново разрабатывается лишь функционал, отражающий новую специфику. На практике концепция использовалась, например, в отраслевом решении для производства ЖБИ и добычи нерудных материалов.

02.03.2017    18284    0    aaw    3    

Как самим написать техническое задание

Техническое задание Россия Бесплатно (free)

Как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. 

21.02.2017    14236    0    user694964_olamikyw    6    

Наблюдения, которые указывают на решимость предприятия к изменениям

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Раздается звонок. - Здравствуйте, это Сергей? Меня зовут (не вникайте в название, но это плоды секундной фантазии), я директор по производству на . У меня есть ряд проблем с производственным планированием. Могли бы мы с вами встретиться? На встрече присутствовал CH3NO2, генеральный директор и, случайно заглянувший, собственник бизнеса. Мне предоставили список технических требований к производственному планированию, наличие которого положительно сказывается как на предметный разговор. В ходе беседы познакомились, поделились коммерческой и организационной информацией, очертили первые шаги.

06.12.2016    18910    0    Gavrik    19    

Технические проблемы взрывного роста компании

Техническое задание Управление проектом Бесплатно (free)

Хочу рассказать об очень интересном проекте, с которым мы недавно столкнулись. В этом проекте необходимо было сделать огромный объем работы за очень короткий промежуток времени, поэтому мы его условно назвали «Марафон со спринтерской скоростью».

26.09.2016    14303    0    R.Tsarenko    27    

Дропшиппинг или "виртуальные" склады поставщиков в 1С

Техническое задание Оптовая торговля Розничная торговля Учет ТМЦ Оптовая торговля Розничная торговля Учет ТМЦ v8 УТ10 УУ Бесплатно (free)

Сейчас всё больше компаний работают по системе дропшиппинг (прямые поставки, когда поставщик отправляет товар непосредственно клиенту, а не продавцу) или продают товар со склада поставщика не закупая его себе на склад (под конкретные заказы покупателей). При этом за частую есть необходимость хранения остатков и цен поставщика, выгрузки их на сайты и другие информационные ресурсы, рассылки в своих прайс листах. В статье рассматриваются варианты отражения подобных операций в управленческих конфигурациях 1С без привязки к конкретной конфигурации. С некоторыми различиями данные схемы можно применить в Управлении торговлей 10 и 11, Рарус:Альфа-авто, Комплексной автоматизации, УПП и др. т.е. в целом в любой конфигурации с возможностью ведения управленческого учета и механизма заказов.

02.09.2016    27999    0    de0nis    17    

Предприятие требует проект автоматизации? Начните правильно!

Техническое задание Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

На нулевом этапе мы не имеем никакого представления о порядке работ, бюджете и сроках достижения статуса «Работает как надо!». Единственное, чем мы можем обладать, — пониманием, что бизнес-процесс работает неэффективно. К сожалению, часто руководители этого не видят или не хотят видеть. Работу необходимо начинать с составления Технических требований проекта 1С автоматизации (оптимизации или бережливого производства).

23.12.2015    23671    0    Gavrik    5    

Большой проект: документация

Техническое задание Управление проектом Бесплатно (free)

Оставим за рамками нашей темы поиск потенциального клиента. Мы его нашли. Вот он - Большой клиент. Чего мы хотим? Хотим заработать. И чтобы этот Большой клиент был у нас не один. А к нам большинство таких клиентов пришли по рекомендации, а для рекомендаций положительных нужно, чтобы Большой клиент был очень доволен сотрудничеством с нами. Но и мы хотели бы быть довольны работой с ним. Вот о том, какими документами мы этого добиваемся, я и попытаюсь рассказать. *** Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года). Также она опубликована в журнале Инфостарта № 3

23.03.2015    20601    0    UR1    5    

Пример ТЗ и ТП на небольшую доработку

Техническое задание v8 БП2.0 Россия Бесплатно (free)

Привожу пример технического задания и технического проекта на небольшую доработку к БП. Документы делались исходя из схемы: Обследование- ТЗ - ТП - Разработка.

14.12.2012    63076    0    SergAn    10    

Как разработать Техническое задание. Часть 2. Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов.

Техническое задание Россия Бесплатно (free)

Как и обещал, пишу вторую часть статьи про разработку Технического задания. В этой части сделан акцент на последовательность и виды работ по сбору информации. Проведена интересная, на мой взгяд, аналогия между работами по описанию бизнес-процессов и разработке Технического задания.

11.04.2012    36178    0    chavalah    34    

Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?

Техническое задание Россия Бесплатно (free)

В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается "как получится". Как сказал Генри Шоу "Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи".

03.04.2012    74226    0    chavalah    55    

Конструирование аналитической структуры плана счетов в программе «1С:Бухгалтерия 8» с целью обеспечения достоверности финансовой отчетности

Управленческий учет (прочее) Дебиторская и кредиторская задолженность Оборотно-сальдовая ведомость, Анализ счета Учет доходов и расходов Дебиторская и кредиторская задолженность Оборотно-сальдовая ведомость, Анализ счета Учет доходов и расходов Учет и отчетность Бухгалтерия Механизмы бухгалтерского учета v8 КА1 БП2.0 УПП1 Россия БУ УУ Бесплатно (free)

Описаны правила конструирования аналитической структуры плана счетов, позволяющей формировать достоверную финансовую отчётность. Описываются принципы формирования баланса и отчета о прибылях и убытках в МСФО и в РСБУ. Даётся определение развёрнутого сальдо и рассматривается его корректное отражение в ОСВ. Делается анализ минимально необходимого количества уровней субконто по счетам расчётов. Подробно рассматриваются ошибки плана счетов «Хозрасчётный» и ОСВ стандартной поставки 1С, препятствующие выверке баланса и отчета о прибылях и убытках по ОСВ. Предлагаются методы купирования проблем.

24.10.2010    168618    0    RayCon    106    

РД 50-34.698-90 - АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ

Техническое задание Россия Бесплатно (free)

Методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливают требования к содержанию ВСЕХ документов, разрабатываемых при создании АС.

06.01.2010    15301    0    nnn123    1    

ГОСТ 34.602-89 (Техническое задание на создание автоматизированной системы)

Техническое задание Управление проектом Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

"Листая старые страницы" времен универа нашел несколько, которыми можно поделиться, не рискуя получить по бошке. :) В общем-то, ничего нового, но думаю, многим может пригодиться.

08.06.2009    31744    0    Оболтус    20    

7 Граблей или история одного IT-директора

Техническое задание Россия Бесплатно (free)

Прежде, получая новую должность, первую неделю я тратил на переезд в новый офис, обустройство кабинета и встречи с новыми подчиненными. Я постепенно входил в курс. Но сейчас не было площадки для разбега. В первый же день, придя на работу, я был ИТ-директором.

08.06.2009    36391    0    GSoft    82    

ГОСТ 24.201-79. ТРЕБОВАНИЕ К СОДЕРЖАНИЮ ДОКУМЕНТА «ТЕХНИЧЕСКОЕ ЗАДАНИЕ»

Техническое задание Россия Бесплатно (free)

Постановлением Государственного комитета СССР по стандартам от 31 января 1979 г. № 383 срок введения установлен с 01.07 1980 г. Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления народным хозяйством (кроме общегосударственного), и устанавливает общие требования к содержанию документа «Техническое задание» (ТЗ) на создание АСУ, кроме АСУ технологическими процессами. В зависимости от вида и назначения АСУ требования, устанавливаемые в настоящем стандарте, допускается конкретизировать в нормативно-технической документации.

29.06.2005    25443    0    support    6