То есть у кандидатов нет времени общаться на неделе, но сделать тестовое, потом hr, а затем еще 3 сессии(алго, дизайн, мейн стек) в свои выходные есть? Серьезно?
И самое главное, ради чего? Это не FAANG(или около бигтех) по престижу и ачивкам, это не FAANG(да даже просто выше рынка) по зп, это не FAANG по обязательствам и ответственности компании(да да, еще помнят как вы кинули своих сотрудников в Армении). Но процесс почему-то как будто вы да.
Если это закрывает ваши потребности в найме, то это хорошо, но не надо доказывать, что это норма для кандидатов
Предположу, что у компания оптимизирует расходы, а россияне, в массе своей, оформлены как ИП/контракторы, которых просто проще и быстрее всего сократить
В то время как например граждане Венгрии(ЕС) оформлены по ТК
Не дай бог. Он же просто будет говорить с командой разработки на разных языках.
Аналитики, QA, автотестры, DevOps-ы как-то говорят с разрабами и понимают друг друга, а вот именно тим-лид не будет
Разработчик берет фичу и оценивает ее в 3 месяца разработки
Во-первых, это ошибка декомпозиции, и как раз тимлид(или сам ПО) должен на нее указать, если такую задачу хотят протащить.
Во-вторых, после декомпозиции задачи оцениваются не 1 человеком, для этого и делаются стори-ревью, планнинги и так далее. Чтобы все были на одной волне, понимали задачи и риски
на выходе через 3 месяца пристойно работающая фича и 5 тысяч строк кода
Пристойно работающая по каким критериям? И какое отношение кол-во строк кода относится к сложности/длительности фичи?
Со стороны бизнеса описание такой фичи может быть любым
Именно поэтому есть ПО и аналитики, чтобы в разработку и тестирование приходила понятная фича с понятными требованиями
От добавь вот тут кнопочку паузы процесса, до разработай 10 форм.
Кнопки какие? Кому доступны? Какие формы? По каким полям фильтруется/сортируется? Кто источник данных? Какие требования по нагрузке?
И много каких еще вопросов.
Если вы решаете брать в работу такое описание требований, то пожалуйста, но кроме вас в этом никто не виноват
Кто и как это в вашей команде с лидом не писавшим код будет решать?
Решать что?
Есть документация, карточки сервиса(со всем бд/топиками/очередями), архитектурные схемы. Если на запрос от соседней команды тимлид начинает реализовывать/фиксить функционал, то это проблема самого тимлида
Это значит, что нужно будет понимать +‑ в целом архитектуру всего проекта.
Нет, более того даже тимлид не обязан понимать архитектуру проекта. Хотя бы потому, что это может быть бывший QA, аналитик, PO
Иметь нужные доступы по работе, подменять иногда тимлида, чтобы при уходе оного в отпуск проект не останавливался в ступоре.
Доступы к чему? Остановился в чем? Тимлид не определяет набор бэклога, например
При необходимости участвовать в совещаниях по планированию и интеграций.
Интеграции также определяет и планирует не тимлид, а посыл именно в этом. Что не отменяет того, что тем кто будет реализовывать функционал, полезно присутствовать на таких обсуждениях
Не замыкаться только лишь на своих задачах и понимать куда идет разработка в целом.
Разработка, как и аналитика и тестирование идет ровно туда, куда определит PO
Уровень soft‑skills должен быть на должном уровне, чтобы можно было вести переговоры с другими командами, решать конфликты внутри команды и не создавать их самому.
Не создавать конфликты навык необходимый в принципе на любой позиции
Проблема в том, что почему-то Team Lead представляется часто, как самый опытный разработчик или же руководитель над другими разработчиками. Но для этого есть другие позиции и роли, например, Tech Lead или SEM
Team Lead вообще не обязан быть бывшим разработчиком, и в его скоуп работ, как и написано в роли, входит организация работы команды, а не ревью/написание кода
Фундамент любой системы это бизнес процессы, которые она автоматизирует В несложных приложениях мб и можно аналитику проектировать бд, но это не его работа и у него нет квалификации.
Вариантов много, начиная от некорректного выбора самой СУБД, например у нас большое кол-во операций записи(или чтения), или требования к распределенному кластеру, или жесткий лимит по времени ответа на выполнения запроса. Но предположим ок, взяли СклСервер/ПГ и вроде даже норм, но теперь проблемы с перфомансом, схемы слишком нормалтхированны. Или монолитная БД теперь бьется на 1 бд на 1 сервис. Да и даже самый банальный кейс, что таблица в бд не равно бизнес сущности
Аналитик формализует бизнес требования, если много интеграций то мб описывает аналитику по входящим/исходящим данным.
Проблемы с тем, что в будущем доработка стоит слишком дорого решает этап проектирования, кто его будет делать(архитектор, техлид, сто, сеньор) выбор каждой компании/команды. И для успешной реализации этого этапа, нужны сформулированные и описанные бизнес кейсы, а не "схема БД"
То есть у кандидатов нет времени общаться на неделе, но сделать тестовое, потом hr, а затем еще 3 сессии(алго, дизайн, мейн стек) в свои выходные есть? Серьезно?
И самое главное, ради чего? Это не FAANG(или около бигтех) по престижу и ачивкам, это не FAANG(да даже просто выше рынка) по зп, это не FAANG по обязательствам и ответственности компании(да да, еще помнят как вы кинули своих сотрудников в Армении). Но процесс почему-то как будто вы да.
Если это закрывает ваши потребности в найме, то это хорошо, но не надо доказывать, что это норма для кандидатов
Я спросил мошенники они или нет, они сказали нет
Скрытый текст
Архитектура начинается с анализа функциональных и не функциональных требований, и поиск баланса в -abilities, а не GOF/SOLID/GRASP
Или с Квай-Гон Джинном)
Предположу, что у компания оптимизирует расходы, а россияне, в массе своей, оформлены как ИП/контракторы, которых просто проще и быстрее всего сократить
В то время как например граждане Венгрии(ЕС) оформлены по ТК
В итоге мы имеем почти 15 летний долгострой, который переносился много раз, с неясными перспективами
"Профсоюз" поддерживает выживание сотрудников, если те не вписываются в "рабоче-крестьянское' движение, найс
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 сервис. Да и даже самый банальный кейс, что таблица в бд не равно бизнес сущности
Аналитик формализует бизнес требования, если много интеграций то мб описывает аналитику по входящим/исходящим данным.
Проблемы с тем, что в будущем доработка стоит слишком дорого решает этап проектирования, кто его будет делать(архитектор, техлид, сто, сеньор) выбор каждой компании/команды. И для успешной реализации этого этапа, нужны сформулированные и описанные бизнес кейсы, а не "схема БД"