Но могу вам дать ещё парочку советов с точки зрения РП и техлида:
договоритесь с тимлидом и пусть он настаивает и проверяет - в каждой задаче должна быть ссылка на вики
В функциональных методах должна быть ссылка на вики или задачу
В папках проекта должен быть read.me файл либо с описанием содержимого, либо снова с ссылкой нс документ.
Введите structurizr для С4. программистам намного проще сопровождать архитектуру с подходом architecture as code
В том же dsl описываются deployment инфраструктура стендов. Можно делать сетевые карты, в props писать порты и ip
Вы сами сказали проблему — вас спрашивают, где искать документ, потому что про его существование либо не знают, либо он не под рукой. Быть «справочным бюро» и бесит и создаётся ощущение, что работа аналитика не важна и не ценится.
Но проблема именно в этой связке - нет никаких проблем создавая метод в коменте к нему добавлять ссылку на задачу. Ничего не стоит при декомпозиции добавлять ссылку на вики в задачу. Сопровождать диаграммы в виде кода, а не тыкаясь в редакторе графическом намного проще и их потом можно парсить и выдавать удобно таблицы сетевых связей, например, компонентов, списки ролей и к чему у них есть доступ. Их все равно потом требует ИБ, а программисты ленивы, если они поймут, что проще такие задачи решать имея С4 в виде кода, они будут так делать.
Забавно, как такие ревью пишут далёкие от понимания технологии. Весь прогресс в ии за счёт скоростных шин передачи данных между процессорами. Разделение кластера даже на десяток кусков ведёт к деградации производительности не в 10 раз, а на два порядка. Кто не верит, может спросить ии.
Поэтому сказки про тысячи небольших цодов на орбите для ии сказки для хомячков.
Вы совершенно правильно описали практику. Я отвечал на другое - у вас прямо в заголовке статьи "как спасать команду от бесконечных митингов". Кто вообще вводит эту практику бесконечных митингов? Именно менеджеры, которые никогда не учились менеджменту, которые "чайка-менеджеры" и вместо помощи в работе и её организации создают ИБД (имитацию бурной деятельности).
К сожалению, "зрелой культуры" сейчас мало где найдёшь. Проблема некомпетентного менеджмента повсеместно.
А на вопрос "как спасать команду от бесконечных митингов" находится совсем в другой плоскости. Если эти митинги организуете вы (не лично вы, не принимайте на свой счёт), то тогда вам не место в менеджменте и нужно пойти подтянуть базу, понять, что проект это время-ресурсы-качество и т.д. По-любому такого менеджера нужно увольнять из проекта, а не учить агенду на митинг писать. Если он не понимает базы, ну научите вы его писать агенду и записывать результаты, но у него пробелы глобальные.
А вот если на своём месте вы всё понимаете, но эти бесконечные ВКС собирают люди повыше типа заказчиков, руководителей и т.д. и приглашают на них по 25 человек, включая разработчиков, тогда это, к сожалению, вопрос из области психотерапии и принятия, ибо уволить своего руководителя и заказчика вы не можете. Тогда вам нужно "лавировать", освобождать своих подчинённых от этих звонков, доносить организаторам, что присутствие всей вашей команды на ВКС это бездарная трата ресурса. И, к сожалению, очень не редко это встречается в штыки этими людьми. Опять по той же причине, что управлять они не умеют, написать письмо, где кратко объяснить суть они не умеют. Им нужно собрать большую конференцию, пятнадцать раз одно и то же проговорить разными способами, услышать вопросы, которые их направят в нужное русло и они родят то, что забыли упомянуть и после этого пойдут домой успокоенными, что "вроде донесли до команды". Хотя на самом деле им нужно было просто сесть и написать документ. Но они просто не умеют формулировать.
Господа менеджеры с двумя классами образования, вам не в техлидов учиться надо, а идти принимать заказы на гамбургеры. Умение организовывать работу это на целое образование.
Эта статья для кого? По принципам этой же статьи? Для тех менеджеров, которые элементарных вещей не понимают?
Тогда пункт 1. - увольняйтесь и не мешайте работать.
Или вы этой статьёй хотите помочь «людям с особенностями в развитии» подольше удерживаться на месте, которое они занимают по чистой случайности?
Поздравляю вас с вступлением в этот мир боли :)
Неприятно, конечно, как Кафка писать «в стол».
Но могу вам дать ещё парочку советов с точки зрения РП и техлида:
договоритесь с тимлидом и пусть он настаивает и проверяет - в каждой задаче должна быть ссылка на вики
В функциональных методах должна быть ссылка на вики или задачу
В папках проекта должен быть read.me файл либо с описанием содержимого, либо снова с ссылкой нс документ.
Введите structurizr для С4. программистам намного проще сопровождать архитектуру с подходом architecture as code
В том же dsl описываются deployment инфраструктура стендов. Можно делать сетевые карты, в props писать порты и ip
Вы сами сказали проблему — вас спрашивают, где искать документ, потому что про его существование либо не знают, либо он не под рукой. Быть «справочным бюро» и бесит и создаётся ощущение, что работа аналитика не важна и не ценится.
Но проблема именно в этой связке - нет никаких проблем создавая метод в коменте к нему добавлять ссылку на задачу. Ничего не стоит при декомпозиции добавлять ссылку на вики в задачу. Сопровождать диаграммы в виде кода, а не тыкаясь в редакторе графическом намного проще и их потом можно парсить и выдавать удобно таблицы сетевых связей, например, компонентов, списки ролей и к чему у них есть доступ. Их все равно потом требует ИБ, а программисты ленивы, если они поймут, что проще такие задачи решать имея С4 в виде кода, они будут так делать.
Забавно, как такие ревью пишут далёкие от понимания технологии. Весь прогресс в ии за счёт скоростных шин передачи данных между процессорами. Разделение кластера даже на десяток кусков ведёт к деградации производительности не в 10 раз, а на два порядка. Кто не верит, может спросить ии.
Поэтому сказки про тысячи небольших цодов на орбите для ии сказки для хомячков.
Вы совершенно правильно описали практику. Я отвечал на другое - у вас прямо в заголовке статьи "как спасать команду от бесконечных митингов". Кто вообще вводит эту практику бесконечных митингов? Именно менеджеры, которые никогда не учились менеджменту, которые "чайка-менеджеры" и вместо помощи в работе и её организации создают ИБД (имитацию бурной деятельности).
К сожалению, "зрелой культуры" сейчас мало где найдёшь. Проблема некомпетентного менеджмента повсеместно.
А на вопрос "как спасать команду от бесконечных митингов" находится совсем в другой плоскости. Если эти митинги организуете вы (не лично вы, не принимайте на свой счёт), то тогда вам не место в менеджменте и нужно пойти подтянуть базу, понять, что проект это время-ресурсы-качество и т.д. По-любому такого менеджера нужно увольнять из проекта, а не учить агенду на митинг писать. Если он не понимает базы, ну научите вы его писать агенду и записывать результаты, но у него пробелы глобальные.
А вот если на своём месте вы всё понимаете, но эти бесконечные ВКС собирают люди повыше типа заказчиков, руководителей и т.д. и приглашают на них по 25 человек, включая разработчиков, тогда это, к сожалению, вопрос из области психотерапии и принятия, ибо уволить своего руководителя и заказчика вы не можете. Тогда вам нужно "лавировать", освобождать своих подчинённых от этих звонков, доносить организаторам, что присутствие всей вашей команды на ВКС это бездарная трата ресурса. И, к сожалению, очень не редко это встречается в штыки этими людьми. Опять по той же причине, что управлять они не умеют, написать письмо, где кратко объяснить суть они не умеют. Им нужно собрать большую конференцию, пятнадцать раз одно и то же проговорить разными способами, услышать вопросы, которые их направят в нужное русло и они родят то, что забыли упомянуть и после этого пойдут домой успокоенными, что "вроде донесли до команды". Хотя на самом деле им нужно было просто сесть и написать документ. Но они просто не умеют формулировать.
Да вы прикалываетесь?
Господа менеджеры с двумя классами образования, вам не в техлидов учиться надо, а идти принимать заказы на гамбургеры. Умение организовывать работу это на целое образование.
Эта статья для кого? По принципам этой же статьи? Для тех менеджеров, которые элементарных вещей не понимают?
Тогда пункт 1. - увольняйтесь и не мешайте работать.
Или вы этой статьёй хотите помочь «людям с особенностями в развитии» подольше удерживаться на месте, которое они занимают по чистой случайности?