Не дай бог. Он же просто будет говорить с командой разработки на разных языках.
Аналитики, QA, автотестры, DevOps-ы как-то говорят с разрабами и понимают друг друга, а вот именно тим-лид не будет
Разработчик берет фичу и оценивает ее в 3 месяца разработки
Во-первых, это ошибка декомпозиции, и как раз тимлид(или сам ПО) должен на нее указать, если такую задачу хотят протащить.
Во-вторых, после декомпозиции задачи оцениваются не 1 человеком, для этого и делаются стори-ревью, планнинги и так далее. Чтобы все были на одной волне, понимали задачи и риски
на выходе через 3 месяца пристойно работающая фича и 5 тысяч строк кода
Пристойно работающая по каким критериям? И какое отношение кол-во строк кода относится к сложности/длительности фичи?
Со стороны бизнеса описание такой фичи может быть любым
Именно поэтому есть ПО и аналитики, чтобы в разработку и тестирование приходила понятная фича с понятными требованиями
От добавь вот тут кнопочку паузы процесса, до разработай 10 форм.
Кнопки какие? Кому доступны? Какие формы? По каким полям фильтруется/сортируется? Кто источник данных? Какие требования по нагрузке?
И много каких еще вопросов.
Если вы решаете брать в работу такое описание требований, то пожалуйста, но кроме вас в этом никто не виноват
Кто и как это в вашей команде с лидом не писавшим код будет решать?
Решать что?
Есть документация, карточки сервиса(со всем бд/топиками/очередями), архитектурные схемы. Если на запрос от соседней команды тимлид начинает реализовывать/фиксить функционал, то это проблема самого тимлида
Это значит, что нужно будет понимать +‑ в целом архитектуру всего проекта.
Нет, более того даже тимлид не обязан понимать архитектуру проекта. Хотя бы потому, что это может быть бывший QA, аналитик, PO
Иметь нужные доступы по работе, подменять иногда тимлида, чтобы при уходе оного в отпуск проект не останавливался в ступоре.
Доступы к чему? Остановился в чем? Тимлид не определяет набор бэклога, например
При необходимости участвовать в совещаниях по планированию и интеграций.
Интеграции также определяет и планирует не тимлид, а посыл именно в этом. Что не отменяет того, что тем кто будет реализовывать функционал, полезно присутствовать на таких обсуждениях
Не замыкаться только лишь на своих задачах и понимать куда идет разработка в целом.
Разработка, как и аналитика и тестирование идет ровно туда, куда определит PO
Уровень soft‑skills должен быть на должном уровне, чтобы можно было вести переговоры с другими командами, решать конфликты внутри команды и не создавать их самому.
Не создавать конфликты навык необходимый в принципе на любой позиции
Проблема в том, что почему-то Team Lead представляется часто, как самый опытный разработчик или же руководитель над другими разработчиками. Но для этого есть другие позиции и роли, например, Tech Lead или SEM
Team Lead вообще не обязан быть бывшим разработчиком, и в его скоуп работ, как и написано в роли, входит организация работы команды, а не ревью/написание кода
Фундамент любой системы это бизнес процессы, которые она автоматизирует В несложных приложениях мб и можно аналитику проектировать бд, но это не его работа и у него нет квалификации.
Вариантов много, начиная от некорректного выбора самой СУБД, например у нас большое кол-во операций записи(или чтения), или требования к распределенному кластеру, или жесткий лимит по времени ответа на выполнения запроса. Но предположим ок, взяли СклСервер/ПГ и вроде даже норм, но теперь проблемы с перфомансом, схемы слишком нормалтхированны. Или монолитная БД теперь бьется на 1 бд на 1 сервис. Да и даже самый банальный кейс, что таблица в бд не равно бизнес сущности
Аналитик формализует бизнес требования, если много интеграций то мб описывает аналитику по входящим/исходящим данным.
Проблемы с тем, что в будущем доработка стоит слишком дорого решает этап проектирования, кто его будет делать(архитектор, техлид, сто, сеньор) выбор каждой компании/команды. И для успешной реализации этого этапа, нужны сформулированные и описанные бизнес кейсы, а не "схема БД"
"Профсоюз" поддерживает выживание сотрудников, если те не вписываются в "рабоче-крестьянское' движение, найс
https://habr.com/ru/articles/808359/
Запись в условно 2 таблицы(ентити и ивент) в рамках 1й транзакции не оч увеличит нагрузку
А чтение ивентов с WAL лога, а не таблицы ивентов, снимет нагрузку с мастера/реплики
Таков путь
смехсверхдержавыЖдем блока гитхаба и всех реджестри по типу нпм/нугет/мавен/гемс и тд
Недавно была кстати статья - https://habr.com/ru/articles/807125/
@it_unionкак быть с правами тимлида?
А макдак это про жарить котлеты..
Когда работал в чешкой компании за дежурство предлагали или x2 или выходной
Ясно понятно
Вы получаете квартиры через апи или парсите сайты?
Аналитики, QA, автотестры, DevOps-ы как-то говорят с разрабами и понимают друг друга, а вот именно тим-лид не будет
Во-первых, это ошибка декомпозиции, и как раз тимлид(или сам ПО) должен на нее указать, если такую задачу хотят протащить.
Во-вторых, после декомпозиции задачи оцениваются не 1 человеком, для этого и делаются стори-ревью, планнинги и так далее. Чтобы все были на одной волне, понимали задачи и риски
Пристойно работающая по каким критериям? И какое отношение кол-во строк кода относится к сложности/длительности фичи?
Именно поэтому есть ПО и аналитики, чтобы в разработку и тестирование приходила понятная фича с понятными требованиями
Кнопки какие? Кому доступны? Какие формы? По каким полям фильтруется/сортируется? Кто источник данных? Какие требования по нагрузке?
И много каких еще вопросов.
Если вы решаете брать в работу такое описание требований, то пожалуйста, но кроме вас в этом никто не виноват
Решать что?
Есть документация, карточки сервиса(со всем бд/топиками/очередями), архитектурные схемы. Если на запрос от соседней команды тимлид начинает реализовывать/фиксить функционал, то это проблема самого тимлида
Нет, более того даже тимлид не обязан понимать архитектуру проекта. Хотя бы потому, что это может быть бывший QA, аналитик, PO
Доступы к чему? Остановился в чем? Тимлид не определяет набор бэклога, например
Интеграции также определяет и планирует не тимлид, а посыл именно в этом. Что не отменяет того, что тем кто будет реализовывать функционал, полезно присутствовать на таких обсуждениях
Разработка, как и аналитика и тестирование идет ровно туда, куда определит PO
Не создавать конфликты навык необходимый в принципе на любой позиции
Проблема в том, что почему-то Team Lead представляется часто, как самый опытный разработчик или же руководитель над другими разработчиками. Но для этого есть другие позиции и роли, например, Tech Lead или SEM
Team Lead вообще не обязан быть бывшим разработчиком, и в его скоуп работ, как и написано в роли, входит организация работы команды, а не ревью/написание кода
Рост от 1640$ до 1686$ за 4 года — солидно.
курс
28.09.2018 1$ = 65,83
28.09.2023 1$ = 97,24
Это все напоминает примерно такое
-- Нам нужен экскаватор
-- Директор сказал нельзя, на лопату
-- Но...
-- На еще Ваню, он нужен для корректной работы лопаты. С вас
5 тысовермного рублейПросто скачать этот продукт, который хочет занять 80% рынка...нельзя! Надо заполнить контактную форму)
Визуально же очень напоминает diagrams.net, запиханный в электрон/вебвью. Репутация же импортозамещенного софта вызывает подозрения что так оно и есть
Фундамент любой системы это бизнес процессы, которые она автоматизирует
В несложных приложениях мб и можно аналитику проектировать бд, но это не его работа и у него нет квалификации.
Вариантов много, начиная от некорректного выбора самой СУБД, например у нас большое кол-во операций записи(или чтения), или требования к распределенному кластеру, или жесткий лимит по времени ответа на выполнения запроса. Но предположим ок, взяли СклСервер/ПГ и вроде даже норм, но теперь проблемы с перфомансом, схемы слишком нормалтхированны. Или монолитная БД теперь бьется на 1 бд на 1 сервис. Да и даже самый банальный кейс, что таблица в бд не равно бизнес сущности
Аналитик формализует бизнес требования, если много интеграций то мб описывает аналитику по входящим/исходящим данным.
Проблемы с тем, что в будущем доработка стоит слишком дорого решает этап проектирования, кто его будет делать(архитектор, техлид, сто, сеньор) выбор каждой компании/команды. И для успешной реализации этого этапа, нужны сформулированные и описанные бизнес кейсы, а не "схема БД"
Но из статьи так и не понял - что именно делают деливери менеджеры?
Чистить доску в жире и считать алерты с графаны? - Так есть тимлид или девопс
Разбираться какие фичи нужны? - Есть продукт овнер
Планировать интеграции? - Есть архитектор и всякие миты, процессы где это обсуждается
Нет противника страшнее, чем союзник-идиот
Ну тут можно только пожелать получить в наследство деплой павершелом, автотесты на баше, ну и свой фреймворк, без доки естесна
И чтоб все было написано чатгпт
Есть именно что продукты, например EnterpriseDB, PostgresPro, модификации типо TimeseriesDB, Greenplum.
А есть просто "отечественный" шильдик, за который берут много деняк
А космические аппараты заменили автомобили, ноутбуки шариковые ручки и так далее