Size: a a a

Работа для ИТ-архитекторов

2021 August 27

RP

Roman Piontik in Работа для ИТ-архитекторов
:)
источник

DA

Dmitry Alexeev in Работа для ИТ-архитекторов
Хороший директор. Годный. Одобряэ.
источник

RP

Roman Piontik in Работа для ИТ-архитекторов
Ответственность должна быть обеспечена правами. Если аналитик отвечает за удовлетворение клиента, значит он должен принимать ВСЕ ключевые решения. В том числе и по ресурсам, срокам, бюджету.

Удовлетворенность же клиента складывается еще с этапа продаж. И заканчивается этапом поддержки при эксплуатации. Очевидно, что аналитик не может удовлетворить клиента. Он может его "умаслить". Пока...

Пока "рыба гниет... или напротив сливает работу всей команды.

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

RP

Roman Piontik in Работа для ИТ-архитекторов
Т.е. данная система, очевидно, также основывается на культуре. Культуре ответственности. Культуре роли.
источник

AP

Alexey Pryanishnikov in Работа для ИТ-архитекторов
Да, именно это примерно все и упускают.

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

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

А нужно, обычно, просто перекроить процессы в организации
источник

ГШ

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

RP

Roman Piontik in Работа для ИТ-архитекторов
Мне кажется именно отсюда и появились продакты. Но не решусь на этом настаивать.
источник

AP

Alexey Pryanishnikov in Работа для ИТ-архитекторов
Да, сейчас вместо "процессы" принято говорить "культура", но на самом деле культура это такие процессы, которые пока что не отвердели на бумаге, а значит в рамках них можно мухлевать, только и всего
источник

AP

Alexey Pryanishnikov in Работа для ИТ-архитекторов
С продактами всё на пару порядков хуже, но это очень долгий срачик получится, если расписывать, что не так с чистым продуктовым подходом
источник

AP

Alexey Pryanishnikov in Работа для ИТ-архитекторов
Отличный пример истории про "мы тут уже продали хер знает что, а вы как архитектор крутитесь как хотите"
источник

ГШ

Григорий Шатров... in Работа для ИТ-архитекторов
Архитектор в этой схеме самым последним попадает под раздачу. 😊
источник

AP

Alexey Pryanishnikov in Работа для ИТ-архитекторов
А это вообще архитектора не волнует.
Архитектора волнует, что по такой схеме в 100% случаев получается неоптимизированное, непереиспользуемое, костыльное и ненастраиваемое одноразовое гуано, а не система.
Это демотивирует, особенно если у архитектора был опыт качественного проектирования на ландшафтном уровне, а не вот этой вот ловли блох фич
источник

RP

Roman Piontik in Работа для ИТ-архитекторов
Григорий, смотрите - я с вами не спорю. Я понимаю о чем вы говорите. Но по сути своей тут есть глубинная проблема в смысле.
1. Клиент не тот кто говорит с аналитиком. Это лишь представитель клиента. Клиент тот кто подписывает договор. Даже не акты.
2. Аналитик лишь фрагмент проекта. Значимый, но фрагмент.

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

Задача аналитика не доставить удовольствие, а выявить ключевые функциональные и нефункциональные требования. Свести все это в кучу и передать на осмечивание руководителю проектов. Этот список трансформируется в план и бюджет. Которые утверждает клиент.

Удовольствие клиент получит не от работы аналитика, а от бизнес-ценности, которую подарит работа аналитика. Оценить это можно только на этапе ввода в эксплуатацию.

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

ГШ

Григорий Шатров... in Работа для ИТ-архитекторов
Поэтому на проектных работах и платят больше, что приходится во всем этом г... "плавать" - аналитикам в меняющихся требованиях, РП в меняющихся бюджетах, а архитекторам в меняющейся архитектуре.
источник

RP

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

AP

Alexey Pryanishnikov in Работа для ИТ-архитекторов
Так ведь наоборот, в продуктовой разработке это же постоянно. Фичи и продукт всех волнует, а что там костыли и велосипеды внутри и следующая фича будет стоить каждый раз дороже и дороже - да похрен, лишь бы маржа текла
источник

RP

Roman Piontik in Работа для ИТ-архитекторов
Конечно, есть процесс управления изменениями. Где уже могут появляться новые требования. И архитектору нужно их как-то учитывать. Но это процесс нормальный.
источник

AP

Alexey Pryanishnikov in Работа для ИТ-архитекторов
Ой. А чат только заметил, что не тот, не для дискуссий )
источник

ГШ

Григорий Шатров... in Работа для ИТ-архитекторов
В продуктовой разработке, мне казалось, сразу определен объем фич на релиз (и возможно переносить сроки более-менее безболезненно). Т.е. там более стабильно всё и нет внешнего Заказчика, который "стучит по столу кулаком" и требует невозможного.
источник

AP

Alexey Pryanishnikov in Работа для ИТ-архитекторов
Но вообще, последние несколько лет убеждён, что индустрии просто выгодно плодить говнософт с хипстерами и продуктологами и понижать планку входа - так больше доработок, процесс внедрения бесконечен, всё работает через задницу, а значит клиент никогда не перестанет платить.

Знали ли авторы анекдота про "ускоряющий цикл" из 2000-х, к чему мы придём...
источник