К основному контенту

Почему проекты умирают. Архитектура

Еще одна штука, которая очень сильно влияет на успешность проекта - это архитектура.

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

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

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

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

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

А теперь выводы:
  • Даже самый способный и грамотный разработчик не способен спроектировать архитектуру, если он не обладает навыками и инструментами ее проектирования. Он способен "накидать". Что-то про три кубика "уровень данных - уровень логики - уровень интерфейсов". Что-то накидать - это про гавно на вентилятор. С такой архитектурой будет обосрана вся команда.
  • Блестяще знает платформы, библиотеки, еще чего-то там и умеет проектировать архитектуры - это две очень большие разницы. См. предыдущий пункт.
  • Сильный системный аналитик проектирует архитектуру лучше сильного разработчика.
  • Схема развертывания и архитектура - это разные вещи.
  • Система - это не только софт, это до хрена всего. И это до хрена всего тоже является частью ее архитектуры. Поэтому у архитектора должно быть понимание, что такое система, что такое корпоративная архитектура, как его архитектура вшивается в корпоративную и что должно быть в его архитектуру включено, чтобы все сшилось. Он должен обладать кругозором.

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

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

И вывод: растите архитекторов в девелоперах с самого раннего возраста. Им всем это пойдет только на пользу. Видеть больше и понимать, что делаешь, пока никому лишним не было.

Комментарии

Популярные сообщения из этого блога

Драйв

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

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

Проект - он как лестница. По нему надо карабкаться вверх, к результату. Не надо вокруг него прыгать. Это бессмысленно.

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

Карта компетенции аналитика

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

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

По сути эти категории образуют слоеный пирог, в основе которого лежат теоретические знания. На основе знаний аналитик пытается что-то сделать и приобретает опыт. Опыт оттачивает навыки, что является основой и движущей силой развития специалиста: нау…

Оценка эффективности работы руководителя проектов

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


Постановка задачи

Необходимо оценить эффективность работы руководителей проектов, выполняющихся по схеме time & material. Сразу оговорюсь, что на мой взгляд предлагаемая методика подходит и для схем fixed coast.

Цель оценки – понять, кто успешно ведет проект самостоятельно, а за кем надо попристальнее присматривать.

Критерии успешности хода проекта:
• Соблюдение бюджета
• Соблюдение плана выполнения проекта
• Отсутствие критических проблем, способных зааффектить бюджет и календарь
• Удовлетворенность Заказчика (субъективно, по отзывам)


В чем идея 

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

Успешность проекта оценивается по критериям, изложенны…