не понял, что значит "разработке новой фирм" - разработке фичи или открытии фирмы?
Имел в виду "фичи" (автозамена сработала)
узкие специалисты будут нужны, вопрос в количестве. Условно, если раньше каждый стартап нанимал себе десяток узкоспециализированных сеньоров, то теперь они будут нанимать одного "на все руки", а за какими-то узко-специальными вопросами призывать аутсорс / аутстафф на время.
Возможно так и будет, вопрос в целях и масштабе. Времена когда сотрудников нанимал впрок закончились.
То есть мы приходим к тому, что при разработке новой фирм нужно привлекать сторонних специалистов (которые тоже не дадут 100% гарантий). И сколько это обойдется в деньгах? В общем из Вашего ответа получается, что нужны узкие специалисты, будь то в штате или аутсорс или аутстаф, что противоречит посылу статьи.
Системы сильно усложнились за последние 10-15 лет. Если вы считаете, что довольно просто настроить безопасную и надежную систему деплоя в облако, то я с вами не соглашусь. Такие ошибки конфигурации могут стоить очень дорого (огромные счета от облачного сервиса, если ты rate limit неправильно настроил).
Например, 10 лет назад, я поднимал виртуалки и настраивал nginx, но с тех по многое поменялось
А потом у вас оказывается случайно торчащий наружу MongoDB с персональными данными и компания влипает на миллионные штрафы, потому что настройка безопасно какого-нибудь AWS совсем не тривиальная задача.
Вы спорите с выдуманным тезисом. Я писал про замену смежных технических функций (DevOps, DBA, Архитектор),
Вы забыли про Security Engineer, QE и Support engineer. Ведь так надежнее будет, сам спроектировал, сам работал, сам протестил, сам задеплоил, сам безопасность проверил, еще и на первой линии поддержки сидишь. Эволюция IT с разделением на специальности ведь просто так случилась, от делать нефиг. /S
Как правило, контрактные тесты являются более легковесными чем E2E, и построены на моках. Им важна только проверка контракта и здесь БД, тоже не нужна. Они выполняются обычно как часть CI. Я недавно активно работал на контрактном тестировании с помощью Pact.
Для тестирования API часто требуется получать или проверять актуальные боевые данные напрямую из базы данных
Зачем для терстирования проверять боевые данные? Тестирование, по идее, должно проводиться в тестовой среде. И для E2E тестов не очень хорошо смотреть во внутренности сервиса (например в базу данных), API сервиса лучше тестировать как "черный ящик", для тестирования внутрянки используются другие типы тестов
Обычно есть грейды разработчика инженера, у каждого грейда своя вилка, чем выше грейд, тем выше вилка.
А чем меньше человек копает лопатой, тем быстрее теряется навык виртуозного владения лопатой.
Здесь я с Вами соглашусь, поэтому и отказываюсь от должности лида, так как, у этого есть свои недостатки: больше митингов, меньше разработки, вероятный переход в другую команду (два лида не нужны в одной команде)
Это скорее всего исключение и повод искать другую работу или работать в режиме должности. Вряд ли в должностных инструкциях написано, что ты должен брать на себя работу, выходящую за рамки твоих обязанностей.
И тогда, да работодателю как-то такого сотрудника надо поощрить, ну в вот ревью это для этого подошло.
В моем понимании, результатом таких переработок должен быть 1:1 встреча с руководителем и выяснение причины переработок: ( низкая компентенция, проблемы в планировании или оценки сложности задачи). То есть, для руководителя переработка - это звоночек, а регулярные переработки - это колокол
Я с вами не соглашусь. Лид != начальник отдела. Многое зависит от компании, по своему опыту скажу, что лид это и сильный разработчик тоже, который больше взаимодействует со стейкхолдерами. Ну и у лида грейд выше, соответственно и ЗП выше
А как тогда сотруднику расти если он не будет брать такие задачи? Просто по выслуги лет? Чтобы стать лидом, нужна брать на себя проекты и показывать лидерские качества
Есть матрица компетенции и должностные обязанности, например старший разработчик руководит разработкой фичи и является ментором для новичков, мидл по тем или иным причинам, взял на себя менторство нового сотрудника, или руководство разработкой новой фичи, вот и получается что он вышел за пределы ожидаемых от него компетенций. А старший разработчик или лид могут быть заняты другими проектами или тупо быть в отпуске, всякое бывает. Вот еще пример, лид команды уволился и старший разработчик исполняет его обязанности, в таком случае он должен получать добавку к зарплате или повышение ( с добавкой)
Не очень понятно, как «превзошел ожидания» соотносится с переработками. Эта оценка относится к должностным обязанностям и компетенциям. Например, есть обязанности и компетенции разработчиков мидла и старшего, если мидл выполняет обязанности старшего, или лида, то в этом случае он «превосходит ожидания»
Замечательно, что у вас внедрены такие практики, и название интересное quite day. Когда писал статью пытался найти название таких мероприятий на русском, так и не нашел :(
Вы в каком-то идеальном мире работаете, а сервис - это сферический конь в вакууме. За мою довольную долгую карьеру в ИТ я встречал много случаев, когда возникали баги на проде. А полностью протестировать сервис невозможно, потому что у сервисов много зависимостей и упасть может где угодно.
Например, сервис выводит какие-то агрегированные данные из внешних сервисов и показывает их на экране и вот внешний сервис в ответ на ваш запрос начинает возвращать неожиданные ответы (изменили тип поля, такое бывает) и экран у вас полностью падает из-за одной зависимости. Тут кто виноват QA или DevOps, а может разработчик, который не ожидал такого и не сделал интеграционный тест? Или зависимости, вы обновляете спринг или том кат (или любую зависимость) и сервис после деплоя падает из-за бага который был. Или QA должен проводить полное тестирование включая нагрузочное, после каждого обновления зависимостей? Я уже не беру различные утечки памяти, некорректные данные в базе данных (например неправильный UUID), отсутствие индексов
Как удобно получается, проектированием и разработкой занимается разработчик, а в случае возникновения проблем виноваты все вокруг, но не он. В таких случаях надо не виновных искать, а проводить постмортем, выявлять где проблема и как ее избежать в будущем.
Я помню проходил оффлайн собесы 2019-2020 годах в крупные компании. Так вот, оффлайн был только один раунд. Компании оплачивали как минимум билеты и проживание + визовую поддержку, иногда и командировочные.
Имел в виду "фичи" (автозамена сработала)
Возможно так и будет, вопрос в целях и масштабе. Времена когда сотрудников нанимал впрок закончились.
То есть мы приходим к тому, что при разработке новой фирм нужно привлекать сторонних специалистов (которые тоже не дадут 100% гарантий). И сколько это обойдется в деньгах? В общем из Вашего ответа получается, что нужны узкие специалисты, будь то в штате или аутсорс или аутстаф, что противоречит посылу статьи.
Системы сильно усложнились за последние 10-15 лет. Если вы считаете, что довольно просто настроить безопасную и надежную систему деплоя в облако, то я с вами не соглашусь. Такие ошибки конфигурации могут стоить очень дорого (огромные счета от облачного сервиса, если ты rate limit неправильно настроил).
Например, 10 лет назад, я поднимал виртуалки и настраивал nginx, но с тех по многое поменялось
А потом у вас оказывается случайно торчащий наружу MongoDB с персональными данными и компания влипает на миллионные штрафы, потому что настройка безопасно какого-нибудь AWS совсем не тривиальная задача.
Вы забыли про Security Engineer, QE и Support engineer. Ведь так надежнее будет, сам спроектировал, сам работал, сам протестил, сам задеплоил, сам безопасность проверил, еще и на первой линии поддержки сидишь. Эволюция IT с разделением на специальности ведь просто так случилась, от делать нефиг. /S
Как правило, контрактные тесты являются более легковесными чем E2E, и построены на моках. Им важна только проверка контракта и здесь БД, тоже не нужна. Они выполняются обычно как часть CI. Я недавно активно работал на контрактном тестировании с помощью Pact.
Зачем для терстирования проверять боевые данные? Тестирование, по идее, должно проводиться в тестовой среде. И для E2E тестов не очень хорошо смотреть во внутренности сервиса (например в базу данных), API сервиса лучше тестировать как "черный ящик", для тестирования внутрянки используются другие типы тестов
Обычно есть грейды разработчика инженера, у каждого грейда своя вилка, чем выше грейд, тем выше вилка.
Здесь я с Вами соглашусь, поэтому и отказываюсь от должности лида, так как, у этого есть свои недостатки: больше митингов, меньше разработки, вероятный переход в другую команду (два лида не нужны в одной команде)
Это скорее всего исключение и повод искать другую работу или работать в режиме должности. Вряд ли в должностных инструкциях написано, что ты должен брать на себя работу, выходящую за рамки твоих обязанностей.
В моем понимании, результатом таких переработок должен быть 1:1 встреча с руководителем и выяснение причины переработок: ( низкая компентенция, проблемы в планировании или оценки сложности задачи). То есть, для руководителя переработка - это звоночек, а регулярные переработки - это колокол
Печально, что такое встречается в бигтехе
Я с вами не соглашусь. Лид != начальник отдела. Многое зависит от компании, по своему опыту скажу, что лид это и сильный разработчик тоже, который больше взаимодействует со стейкхолдерами. Ну и у лида грейд выше, соответственно и ЗП выше
А как тогда сотруднику расти если он не будет брать такие задачи? Просто по выслуги лет? Чтобы стать лидом, нужна брать на себя проекты и показывать лидерские качества
Есть матрица компетенции и должностные обязанности, например старший разработчик руководит разработкой фичи и является ментором для новичков, мидл по тем или иным причинам, взял на себя менторство нового сотрудника, или руководство разработкой новой фичи, вот и получается что он вышел за пределы ожидаемых от него компетенций. А старший разработчик или лид могут быть заняты другими проектами или тупо быть в отпуске, всякое бывает. Вот еще пример, лид команды уволился и старший разработчик исполняет его обязанности, в таком случае он должен получать добавку к зарплате или повышение ( с добавкой)
Не очень понятно, как «превзошел ожидания» соотносится с переработками. Эта оценка относится к должностным обязанностям и компетенциям. Например, есть обязанности и компетенции разработчиков мидла и старшего, если мидл выполняет обязанности старшего, или лида, то в этом случае он «превосходит ожидания»
Жаль слышать такое. Думаю, что для менеджеров выгода от такой формы работы неочевидна, поэтому и не дают время на это.
Замечательно, что у вас внедрены такие практики, и название интересное quite day. Когда писал статью пытался найти название таких мероприятий на русском, так и не нашел :(
Вы в каком-то идеальном мире работаете, а сервис - это сферический конь в вакууме. За мою довольную долгую карьеру в ИТ я встречал много случаев, когда возникали баги на проде. А полностью протестировать сервис невозможно, потому что у сервисов много зависимостей и упасть может где угодно.
Например, сервис выводит какие-то агрегированные данные из внешних сервисов и показывает их на экране и вот внешний сервис в ответ на ваш запрос начинает возвращать неожиданные ответы (изменили тип поля, такое бывает) и экран у вас полностью падает из-за одной зависимости. Тут кто виноват QA или DevOps, а может разработчик, который не ожидал такого и не сделал интеграционный тест?
Или зависимости, вы обновляете спринг или том кат (или любую зависимость) и сервис после деплоя падает из-за бага который был. Или QA должен проводить полное тестирование включая нагрузочное, после каждого обновления зависимостей? Я уже не беру различные утечки памяти, некорректные данные в базе данных (например неправильный UUID), отсутствие индексов
Как удобно получается, проектированием и разработкой занимается разработчик, а в случае возникновения проблем виноваты все вокруг, но не он. В таких случаях надо не виновных искать, а проводить постмортем, выявлять где проблема и как ее избежать в будущем.
Я помню проходил оффлайн собесы 2019-2020 годах в крупные компании. Так вот, оффлайн был только один раунд. Компании оплачивали как минимум билеты и проживание + визовую поддержку, иногда и командировочные.