RT
Иными словами, технологическое руководство с регулярным заходом на поляну к бизнесу
Size: a a a
2020 August 05
GK
В чём разница CTO и архитектора?
ОИ
а вас последнее время архитектор кусал?
Нет, у меня сейчас чувство как во Вьетнаме: вроде архитектор есть, но я его не чувствую )))
https://youtu.be/oonNOLjvQh8
https://youtu.be/oonNOLjvQh8
RT
В чём разница CTO и архитектора?
на мой взгляд в маленькой компании разница невелика. разница в большой компании, CTO становится полностью административной позицией, там про планы-ресурсы-бюджеты.
GK
Всем привет!
Сегодня похоже, что я начал чувствовать границу между системным аналитиком и архитектором.
На всякий случай хочу уточнить своё предположение у вас.
Как системный аналитик сперва у меня было 80% времени на разработку технического решения и 20% времени уходило на сопутствующие работы (согласования, брифинги).
В течении года было выполнено около 4 больших проекта и кучка маленьких. Ьольшие проекты до сих пор находятся в ongoing статусе.
В каждый квартал теперь необходимо закидывать доработки по каждому сервису.
На текущий момент у меня 70% работы уходит на согласования, брифинги, разбор вариантов доработок сервисов (идей).
При этом приходится постоянно переключаться (вникать) между проектами.
Всего 30% времени остаётся на формирование технического решения, т.е. "полевой работы", всё больше на "вникание" и "принятие решений".
Результат записывается на более высоком уровне абстракции, т.к. детали уже не успеваю записывать.
Получается эдакое "архитетурное всплытие" по уровню абстракции xD. Уход от детального описания на цепочку "увидеть проблему" - "понять как решать" - "выдать резолюцию".
Так вот к вопросу. Так архитекторы и рождаются? =)))
Сегодня похоже, что я начал чувствовать границу между системным аналитиком и архитектором.
На всякий случай хочу уточнить своё предположение у вас.
Как системный аналитик сперва у меня было 80% времени на разработку технического решения и 20% времени уходило на сопутствующие работы (согласования, брифинги).
В течении года было выполнено около 4 больших проекта и кучка маленьких. Ьольшие проекты до сих пор находятся в ongoing статусе.
В каждый квартал теперь необходимо закидывать доработки по каждому сервису.
На текущий момент у меня 70% работы уходит на согласования, брифинги, разбор вариантов доработок сервисов (идей).
При этом приходится постоянно переключаться (вникать) между проектами.
Всего 30% времени остаётся на формирование технического решения, т.е. "полевой работы", всё больше на "вникание" и "принятие решений".
Результат записывается на более высоком уровне абстракции, т.к. детали уже не успеваю записывать.
Получается эдакое "архитетурное всплытие" по уровню абстракции xD. Уход от детального описания на цепочку "увидеть проблему" - "понять как решать" - "выдать резолюцию".
Так вот к вопросу. Так архитекторы и рождаются? =)))
И проконтролировать, чтобы эту резолюцию задизайнили все кто должен и как надо.
ОИ
Иными словами, технологическое руководство с регулярным заходом на поляну к бизнесу
А что делать с документацией? Я перестаю нормально формировать детальные требования, ограничения, схемы. Нужно искать аналитика, который этим будет заниматься?
RT
типа да. поднимаешься на более высокий уровень абстракции, технические детали нужно отпускать
GK
на мой взгляд в маленькой компании разница невелика. разница в большой компании, CTO становится полностью административной позицией, там про планы-ресурсы-бюджеты.
Планы-бюджеты-ресурсы это разве не ИТ-директор (CIO)?
GK
типа да. поднимаешься на более высокий уровень абстракции, технические детали нужно отпускать
Тех детали по всем срезам должны спроектировать и задокументировать исполнители, среди которых софтверные архитекторы, инфраструктурные архитекторы и т.п.
F
Если вы что то не успеваете значит у вас неправильно построена работа. Брать младшего аналитика (читай стенографиста скорей всего) - дело постороения работы и расхода ресурсов. И вообще за такое PM должен рассчитывать, арх или аналитик вы, и возможно ли брать лаборантов.
П
А что делать с документацией? Я перестаю нормально формировать детальные требования, ограничения, схемы. Нужно искать аналитика, который этим будет заниматься?
Или архитектора которого будешь чувствовать
F
Тех детали по всем срезам должны спроектировать и задокументировать исполнители, среди которых софтверные архитекторы, инфраструктурные архитекторы и т.п.
Аналитиков в конторы берут, потому что считают что исполнители должны исполнять а не документировать. И доля здравого смысла в этом есть.
ОИ
типа да. поднимаешься на более высокий уровень абстракции, технические детали нужно отпускать
Тут дилемма возникает - ждут от меня и документов подробных и разбор проблем/принятие решений быстрых и норму 5-ти встреч в день.
Понятно, что надо договариваться, но тут можно либо СА работать, либо архитектором.
До какой-то границы можно совмещать используя тайм-менеджмент, но я вскоре даже это не будет помогать - только увеличение рабочего времени.
Понятно, что надо договариваться, но тут можно либо СА работать, либо архитектором.
До какой-то границы можно совмещать используя тайм-менеджмент, но я вскоре даже это не будет помогать - только увеличение рабочего времени.
ОИ
ПашМиш
Или архитектора которого будешь чувствовать
Да, хотелось бы. =)
F
Конторе выгоднее оставить вас как арх. На все руки. А лучше аналитиком который и вечером задержится. Тут только ваша способность и возможность конторы ресурсы получить.
GK
Аналитиков в конторы берут, потому что считают что исполнители должны исполнять а не документировать. И доля здравого смысла в этом есть.
Будет бесполезная документация. Да, такая тоже нужна для формальной сдачи проектов.
RT
По моему опыту снова все упирается в квалификацию команды разработки. С хорошей командой достаточно лишь нарисовать общий контекст системы, сформулировать функциональные требования. Дальше команда уже сама знает и умеет сделать все годным способом. Если у вас команда джунов, то сколько не пиши документацию во всех подробностях, а унитаз все равно прикрутят к потолку (по аналогии с персонажами из 6-ти кадров).
Я хочу сказать что объем и подробность документации сильно зависят от квалификации и стабильности команды.
Чем чаще меняются люди и ниже из квалификации, тем подробнее и больше приходится писать разных бумаг.
Я хочу сказать что объем и подробность документации сильно зависят от квалификации и стабильности команды.
Чем чаще меняются люди и ниже из квалификации, тем подробнее и больше приходится писать разных бумаг.
GK
По моему опыту снова все упирается в квалификацию команды разработки. С хорошей командой достаточно лишь нарисовать общий контекст системы, сформулировать функциональные требования. Дальше команда уже сама знает и умеет сделать все годным способом. Если у вас команда джунов, то сколько не пиши документацию во всех подробностях, а унитаз все равно прикрутят к потолку (по аналогии с персонажами из 6-ти кадров).
Я хочу сказать что объем и подробность документации сильно зависят от квалификации и стабильности команды.
Чем чаще меняются люди и ниже из квалификации, тем подробнее и больше приходится писать разных бумаг.
Я хочу сказать что объем и подробность документации сильно зависят от квалификации и стабильности команды.
Чем чаще меняются люди и ниже из квалификации, тем подробнее и больше приходится писать разных бумаг.
+
F
По моему опыту снова все упирается в квалификацию команды разработки. С хорошей командой достаточно лишь нарисовать общий контекст системы, сформулировать функциональные требования. Дальше команда уже сама знает и умеет сделать все годным способом. Если у вас команда джунов, то сколько не пиши документацию во всех подробностях, а унитаз все равно прикрутят к потолку (по аналогии с персонажами из 6-ти кадров).
Я хочу сказать что объем и подробность документации сильно зависят от квалификации и стабильности команды.
Чем чаще меняются люди и ниже из квалификации, тем подробнее и больше приходится писать разных бумаг.
Я хочу сказать что объем и подробность документации сильно зависят от квалификации и стабильности команды.
Чем чаще меняются люди и ниже из квалификации, тем подробнее и больше приходится писать разных бумаг.
Еще от их мотивации. Часто встречается, так в ТЗ это не дописали, мы не делаем. Хотя все понимали что только так. Они не мотивированы и им плевать.
ОИ
По моему опыту снова все упирается в квалификацию команды разработки. С хорошей командой достаточно лишь нарисовать общий контекст системы, сформулировать функциональные требования. Дальше команда уже сама знает и умеет сделать все годным способом. Если у вас команда джунов, то сколько не пиши документацию во всех подробностях, а унитаз все равно прикрутят к потолку (по аналогии с персонажами из 6-ти кадров).
Я хочу сказать что объем и подробность документации сильно зависят от квалификации и стабильности команды.
Чем чаще меняются люди и ниже из квалификации, тем подробнее и больше приходится писать разных бумаг.
Я хочу сказать что объем и подробность документации сильно зависят от квалификации и стабильности команды.
Чем чаще меняются люди и ниже из квалификации, тем подробнее и больше приходится писать разных бумаг.
Ещё важно уточнить, что сложность сервиса тоже является величиной, влияющей на это дело. Если сервис жирноват, а функций/правил много, то хочу я того или не хочу - писать придётся много.