Я - ЗУПер! Часть 2. Классификация проектов и задач

Если Вы не читали первую часть, предлагаю это сделать! Т.к. вторая статья является логическим продолжением. Вот ссылка на неё и на продолжение:

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Я - ЗУПер! Часть 3. Ошибки работодателей и соискателей. Плюсы специализации на одной предметной области

Напомню цели статей:

1. Рассказать об объёме знаний в своей предметной области, который должен быть у сильного разработчика. (Часть первая)

2. Донести до потенциальных работодателей потенциальный риск набора универсальных солдат.

3. Для ответа на вопрос: "Для кого плохо?", составим классификацию проектов и решаемых задач. (Часть вторая)

4. Рассмотрим проблемы, возникающие при трудоустройстве. Какие ошибки делают работодатели и соискатели? Как их исправить? (Часть третья)

5. Рассказать аудитории читателей данного материала о плюсах специализации на одной предметной области. 

6. Побудить коллег, прежде всего руководящий состав, при выполнении проектов думать не только о прибыли, но и о качестве!

Рассказ на основе реального опыта (Часть четвертая).

7. Рассмотреть разницу в уровне знаний разработчиков с "одинаковым" набором заявленных в резюме компетенций.

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

Первая классификация проектов (по типу проекта):

1. Проект внедрения. 

2. Проект сопровождения.

Это важный аспект, т.к. на внедрении требуются одни компетенции, в сопровождении другие. Чуть ниже будет подробнее.

Вторая классификация (по размеру организации):

1. Проект федерального масштаба. Признаки такого проекта:

-- Более 50 филиалов

-- Многие выделены как отдельные юридические лица

-- Разноплановость деятельности разных филиалов (дочерних обществ)

-- Как вытекающее - совершенно разный учет (бухгалтерский, налоговый, кадровый), обусловленный сферой деятельности

2. Крупная организация. Признаки такого проекта:

-- Одно или несколько однотипных предприятий + администрация. 

-- Подразделения не выделены в отдельные юридические лица. Языком 1С - это справочник "Подразделения организаций".

-- Сфера деятельности обособленных подразделений совпадает, просто широкая география присутствия. 

-- Как вытекающее - есть возможность наладить централизованный учет в одном месте, чаще всего в Москве.

3. Обычная организация. Признаки такого проекта:

-- Отсутствуют обособленные подразделения

-- Одна-две сферы деятельности

-- Простой учет, часто подходит типовая конфигурация.

4. Так называемый мелкий бизнес или ИП. Здесь всё понятно без слов.

От этой классификации зависит объём входящих проблем и потребности в архитекторах, разработчиках, аналитиках, тестировщиках. 

Также, чем больше проект - тем сложнее и длиннее по времени решаемые задачи.

Последняя третья классификация проектов (по виду исполнителя):

1. Работа на стороне подрядчика, т.е. в интеграторе/франчайзи

2. Внутренний проект (свой отдел разработки в ИТ-отделе)

3. Аутсорсинг ведения бухгалтерского, кадрового учета и расчета заработной платы. Это также внутренний проект, но совсем другая специфика.

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

Классифицируем задачи, возникающие на проектах:

1. Ключевые задачи проекта.

Есть задачи, которые или команда целиком или кто-то один выполняет месяцами. Без этих задач остальные можно вообще не делать, они Вам не помогут! 

Примеры таких задач: 

-- Миграция данных

-- Закрытие месяца

-- Управленческая отчетность

-- Расчет налогов и налоговая отчетность и т.д.

В моём опыте были такие:

• Для одной из дочек Газпрома нужно было доработать не обновляемую УПП версии 1.1 (актуальная была 1.3). Цель - перенос из нового релиза алгоритма расчета страховых взносов под новое законодательство. В тот момент появились Классы условий труда. 
• Для металлургического завода необходимо было разработать механизм расчета сдельной оплаты труда. Начиналось всё с автоматического расчета расценок на каждую операцию на основании данных штатного расписания, а заканчивалось рассчитанным сменным заданием. Стоит упомянуть, что вариантов расчета сдельной оплаты было около 20. 
• Для буровой компании важно было сделать распределение затрат на оплату труда по договорам и номерам скважин. Акт выполненных работ был подписан сразу после заливки проводок за 1 месяц в бухгалтерскую программу.
• В Роснефти необходимо было просто в любом виде запустить пилотный проект с учетом методологии кадрового учета и расчета заработной платы ЕКШ (Единый корпоративный шаблон). 
• Для текущего проекта - отказ от ведения кадрового учета в Access и разных базах УПП в пользу одной базы УПП. + дальнейший перевод УПП на ЗУП 3.1. Первая задача на этапе сдачи работ.

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

2. Масштабные задачи.

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

Примеры таких задач:

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

-- Автоматизация расчета премиального фонда. Тоже не очень сложно, но отражается на каждом сотруднике.

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

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

3. Сложные задачи.

К сложным задачам отнесём:

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

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

-- Затрагивается несколько бизнес-процессов

-- Длительность задач превышает месяц

При выполнении таких задач требуется глубокая проработка сценариев. Всем участникам процесса должно быть понятно:

-- Какие из существующих сценариев дорабатываются

-- В чём ошибка в существующем сценарии работы

-- Как должен работать сценарий после доработки

-- Какие смежные бизнес-процессы затрагивает доработка

При выполнении таких задач довольно высока цена ошибки. После разработки требуется тщательное тестирование на соответствие ожидаемым результатам. 

4. Средние задачи.

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

Критериями задач являются:

-- Понятная предметная область, не требующая специфичных знаний

-- Дорабатывается один или несколько объектов метаданных

-- Задача выполняется в рамках одного бизнес-процесса

-- Длительность задач не превышает одного месяца

-- Чаще всего задачу выполняют 1-2 человек (аналитик + разработчик)

5. Простые задачи.

К простым задачам отнесем добрую половину задач сопровождения и, так называемых, "хотелок". 

Критериями задач являются:

-- Срок реализации от нескольких дней до нескольких недель

-- Выполняется одним человек

-- Чаще всего задача в рамках одного объекта метаданных

-- Большинство отчетов и печатных форм относятся к простым задачам

Теперь вернёмся к классификации проектов... 

Опишу, по своему опыту, какие задачи чаще всего возникают на таких проектах.

Первая классификация:

1. Проект внедрения

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

Большая часть этих задач одновременно сочетают в себе признаки масштабных и сложных задач.

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

В отдельной статье Ни в ЗУП ногой!? А мне нравится! Часть 4. Главное - правильный перенос данных! уже описывал сложность и важность этой задачи. Часто, из 5 описанных этапов выполняют только последний - Выверку перенесенных данных. Обычно этапы переноса отбрасывают по следующим мотивам:

А. Цель переноса и так понятна, смысл её описывать - начать работу в новой системе. Пропускаем

Б. Корректность данных - это ответственность заказчика, нам что дали, то и переносим! Мы, как разработчики, отвечаем только за инструмент. Пропускаем

В. Объём переносимых данных часто определяет заказчик. Первое, что можно от него услышать: "Переносим ВСЁ!", некоторые заказчики даже обсуждать не хотят. Переубедить удаётся лишь в процессе выполнения задачи, когда корректно определены цели переноса и выполнена проверка исходных данных. Когда заказчик видит в старых и ненужных данных кучу ошибок, он сразу же становится лояльнее! Но т.к. большинство делают "как просит заказчик" - данный этап пропускают.

Г. Нормализация справочной информации довольно часто является частью проекта. По этой замечательной причине этот пункт всё таки выполняется. Но тоже не все видят в этом пользу.

На самом деле, если Вы не выполнили первые 4 этапа, 5-й тоже можно не выполнять! Ибо ничего корректного в новую систему не попало! Разве что случайно...

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

Приведу ещё несколько примеров ключевых задач из моего опыта:

• Распределение затрат на оплату труда, налоги и взносы по договорам/скважинам (иными словами по Местам Возникновения Затрат или коротко МВЗ).

Задача выполнялась для буровой организации более 10 лет назад. МВЗ никоим образом не совпадали с подразделениями. Один работник в течение дня мог сменить до 3-х МВЗ.

Т.е. нужно было указывать МВЗ на каждый день по каждому работнику, с указанием отработанного на МВЗ времени. Для решения задачи был создан управленческий табель. Он решал следующий спектр задач:

-- Учет отработанного времени по вахтовым графикам

-- Частая смена графиков (постоянно сотрудники менялись сменами)

-- Ввод фактического времени

-- Ввод отклонений

-- Ввод данных по МВЗ

-- Автоматическое формирование регламентированного табеля

-- Автоматическое формирование кадровых документов отклонений.

Отработанное время по МВЗ было базой для распределения затрат по МВЗ. Доработан был алгоритм формирования проводок. Но это была не самая интересная часть задачи. 

Необходимо было затраты всех управленческих подразделений и должностей распределить пропорционально затратам основных рабочих. Здесь заказчик предоставил сложный алгоритм, который также был реализован. 

Т.е. данная ключевая задача была решена в 2 этапа. Сначала реализовано накопление данных об отработанном времени по МВЗ (и другие задачи по отработанному времени), а потом реализовано само распределение. Это сделало задачу ещё и масштабной и т.к. речь о проводках ещё и сложной) 

• Другой пример - автоматизация работы циркового конвейера. Как понятно из названия задачи речь про Росгосцирк. Опишу сложности:

-- Главной проблематикой этой организации было то, что выплаты производились не в какие-то фиксированные даты. Всё зависело от периода гастролей. 

-- Расчет зарплаты производился бухгалтером в каждом отдельном филиале))) А филиалов 54. В головной организации рассчитывали только отклонения, т.е. б/л, отпуска, простой, репетиционный период.

-- Т.е. если посмотреть на период гастролей, он составлял примерно 45 дней. Начало никогда не привязывалось к началу или середине месяца. Т.е. гастроли с 25 октября по 10 декабря - это норма! И вот тут начиналось самое интересное... 

-- Для бухгалтера филиала возникало 3 расчетных периода: 25.10-31.10; 01.11-30.11; 01.12-10.12. 

-- Накладываем на это то, что артисты часто совмещают должности циркового конвейера (относятся к головной организации с разъездным характером работы), с административными должностями филиалов (отдельные юр. лица с выделенным балансом). 

-- НДФЛ уплачивается по месту выполнения работы. Т.е. база за каждый отдельный расчетный период должна быть учтена отдельно. Использован механизм территорий в ЗУП 3.

-- Вычеты по НДФЛ кем должны применяться? В головной компании или в филиале? Получалась чехарда, кто первый начислил тому и вычеты) Пришлось переделывать под другую логику: где оплачивается первый период, в котором хватает дохода для применения вычета, там он и применяется. Вне зависимости от очередности ввода данных нормально работает, в т.ч. учитывается, применен вычет или нет (Здесь практически стандартный механизм использовался).

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

-- Исходя из описанного, становится понятно, что периоды начислений должны разбиваться на периоды, как указано выше, и по этим периодам рассчитываться. Типовой ЗУП этого совсем не умеет.

Задача была решена добавлением управленческого документа "Формирование гастролей" и доработкой большого количества типовых модулей. К сожалению иначе никак. 

Попутно было исправлено огромное количество проблем при расчете НДФЛ и страховых взносов, связанных с использованием территорий и работой в нескольких филиалах в течение месяца. 

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

2. Проект сопровождения

В проектах сопровождения участвовал всего пару раз за всё время. Сделал очень важный вывод - это вообще не моё! Поэтому при поиске работы пропускаю проекты сопровождения. Однако, было полезно поработать в таком проекте!

Что не так в проектах сопровождения? Опишу своё мнение. У всех оно может быть разное...

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

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

Но всё же один раз повезло! Досталась сложная и одновременно масштабная задача:

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

Постановка задачи на момент выдачи задачи звучала так:

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

А вот выполненную задачу можно описать вот так:

-- Выполнена доработка не обновляемой конфигурации УПП ред. 1.1 в части расчета страховых взносов. В тот момент появились классы условий труда. Ещё мало где была проведена спец. оценка условий труда.

-- Из редакции 1.3 полностью перенесена вся структура данных, необходимая для расчет доп. взносов по классам условий труда.

-- Доработана форма отчетности РСВ-1. Было обновлено огромное количество кода, который участвует в её заполнении и расчете страховых взносов.

-- Страховые взносы за 1-й квартал были пересчитан заново, т.к. они были рассчитаны без учёта классов условий труда.

-- В процессе перерасчета выявлены и исправлены тонны ошибок. По сути проведен аудит расчета взносов за текущий год для 7500 сотрудников в 24 филиалах.

-- Отчетность по всем филиалам за 2 квартала была сдана полностью в автоматическом режиме. Ручные корректировки были запрещены.

Думаю, очевидна разница между исходной постановкой и реально выполненной работой.

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

Третья классификация:

1. Работа на стороне подрядчика

Большая часть моего опыта связана с работой именно на стороне подрядчика.

Какие плюсы были в моём опыте:

• Просто огромное количество возможностей для роста компетенций. Это и предметная область, и разработка, и знания по тиражным решениям...
• Большинство самых масштабных и сложных задач мною получены и выполнены именно работая в интеграторе.
• Можно зайти в практически любой должности (имею ввиду вплоть до руководящей) на крупнейшие проекты страны/города/области.
• Во многих компаниях коллеги готовы помочь. Но, к сожалению не во всех! Сталкивался лично с таким.
• Практически безграничное доверие при реализации задач. До поры до времени))))...

Какие минусы работы в интеграторе:

• Надо прям вот вкалывать! Это не то место, где можно отсидеться в уголке и получать хорошую зарплату! Результат твоей работы - это не жопочасы и не оклад! Результат - это прибыль компании.
• Часто ненормированный рабочий день. Особенно в период старта проекта. За много лет работы в этой сфере не помню ни одного Нового Года, в который можно было не работать... Всегда был запуск чего-нибудь, чаще всего что-то не успеваем и пашем круглые сутки кроме 1 января) Этот год не будет исключением!
• Из-за такого режима очень мало времени на семью. Не всем подходит...
• К сожалению слово прибыль часто является синонимом плохого качества. Крайне тяжело убедить руководителя в необходимости сделать качественно. Уже писал в статьях о новом дурацком термине "приемлемое качество". Тут поможет настойчивость и железные аргументы! Ну и то самое безграничное доверие)
• Не везде можно работать долго. Часто работодатели закрывают потребность на 1 проект и далее опять в поисках.
• Надо быть прям стрессоустойчивым! Здоровый пофигизм здесь не сработает))) 

Работа в сложных условиях делает работника готовым к любым сложностям в будущем. Меня удивить чем-то уже сложно))) Разве что адекватностью!

2. Внутренний проект (свой отдел разработки в ИТ-отделе)

В нескольких проектах приходилось вынужденно переходить на сторону заказчика, т.к. с подрядчиком не получалось выполнить работу в нужном качестве. При этом заказчик в полной мере понимал потребность в качественной работе. Благодаря этому удавалось довести проект до конца! Один из таких проектов металлургический завод в подмосковье. Разработанные алгоритмы работают по сей день (на момент написания статьи), и работают правильно! Уже 8 лет как проект завершен.

Работу в фирме 1С также можно считать внутренним проектом. 

Последние 2 проекта, в которых работаю как самозанятый/ИП тоже отнесу к внутренним проектам. Поясню почему: нет того самого, зловредного понятия "прибыль". Есть оговоренная оплата труда, по сути та же зарплата. Для заказчика это даже выгодней! Экономия в 7% на НДФЛ и 30 на страховых взносах (для ИТ-компаний 15).

Какие плюсы были в моём опыте:

• УРА!!! Можно делать КАЧЕСТВЕННО, а не В СРОК)))

Считаю это главным плюсом работы на внутренних проектах. Здесь можно обоснованно подвинуть сроки вправо без скандалов и уговоров. НО! Обязательно нужно обосновывать! Ведь внутренний заказчик тоже что-то ожидает в обговоренные сроки. В моём опыте сдвиг сроков вправо является вынужденно нормальным. Ведь это ЗУП) Предсказать сроки в этой конфигурации наверно только Ванга могла бы...

• Более спокойная атмосфера работы.

Во внутренних проектах нет ежедневных летучек и прочих бесполезных мероприятий, которые присущи работе на стороне подрядчика. Совещания в лучшем случае раз в неделю, протоколы таких совещаний пишут крайне редко. В общем все заняты делом, а не его обсуждением))) Во время работы на проекте Роснефть, в должности архитектора, совещания были почти каждый день. Помню, максимум их было 7 за один день!))) Это помимо того, что только ленивый не звонил архитектору, чтоб что-нибудь уточнить. Со временем удалось снизить этот поток, доказав бесполезность частых совещаний. Звонки были переадресованы на консультантов. Но реально удавалось поработать с 18 до 22 и по выходным.

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

Какие минусы работы на внутреннем проекте:

• Главным минусом считаю волатильность внутренних заказчиков.

Сроки ж не сильно горят? С точки зрения работодателя мы одинаковы, просто в разных отделах. Нельзя ж сказать, что работа ИТ важнее работы отдела кадров или бухгалтерии!? Особенно, если учесть что ИТ для них и работает. Они всегда аврально заняты! Либо закрытие месяца, либо работой с большим количеством текучки. Половина персонала выполняет важные поручения генерального директора и, в целом, им не до нас. 

• Часто зарплаты несколько ниже рынка.

Считается, что "домашняя" атмосфера и корпоративные "плюшки" это компенсируют. Ну и главный аргумент: "Твоя ж работа не приносит прибыль")))) Однако, если ты ИП или самозанятый - готовы платить по рынку. Понятно, что за счет отсутствия плюшек, годового бонуса и снижения налоговой нагрузки. 

3. Аутсорсинг ведения бухгалтерского, кадрового учета и расчета заработной платы

Здесь сразу скажу, что никогда в своём опыте не работал в таких компаниях! НО! Многократно проходил собеседования. Самая крупная и известная компания - Ernst & Young. 

На мой взгляд, работа на таких проектах - это смесь бульдога с носорогом... Для начала разберемся, кто является заказчиком?! Это либо кадровик, либо расчетчик, оказывающий аутсорсинговые услуги.

Сложности работы в таких компаниях:

• Часто бывает так, что кадровый учёт организация ведёт сама, а вот расчет зарплаты и сдача отчетности на аутсорсинге. Хуже всего - когда эти 2 части учёта ведутся в разных базах, при хороших обстоятельствах есть обмен между базами. Найти "виноватого" капец как тяжело).
• В такой компании организаций очень много. Все они разноплановые! Поэтому нужно иметь разноплановый опыт и знания в предметной области, чтоб на одном языке разговаривать с внутренним заказчиком. 
• Несмотря на разноплановость организаций, задачи довольно однотипные! В основном они связаны с обменами. При заходе новых клиентов - это перенос данных, часто чёрт-те откуда... Надо прям любить заниматься этим. Мне лично нравится больше решать сложные учётные задачи.
• Вторая часть задач - обновление всех конфигураций. Т.к. многие из них не типовые... Тут тоже надо прям любить заниматься обновлением))) 
• Третья часть задач - печатные формы и разгребание ошибок в отчетности. Для ЗУПа это катастрофичные задачи, печатные формы не входят в ТОП-5 любимых задач))) 

Примерно по этим причинам мне не довелось работать в таких компаниях. 

Прочитав всю эту информацию, есть возможность ответить на один из важнейших вопросов:

"Где можно использовать универсальных солдат, а где требуются специализация на одной предметной области"?

Но сделаем это в третьей части статьи) Здесь и так уже много букв...

Напомню ранее написанные статьи с общим названием "Ни в ЗУП ногой?!  А мне нравится!":

1. Главные сложности решения, что отталкивает?

Статьи под общим названием "Как читать чужой код?":

Часть 1. Общие вопросы. Доработка чужого кода. Code review.

Статья про роль и значимость архитектора на проекте:

1. Кто такой архитектор. Редакция 2!