Статья полезная, спасибо! Но ещё в самом начале глаз зацепился за фразу и обронил суровую слезу.
продумайте, как будете отдыхать вечерами после работы: что вас быстрее и качественнее восстановит
Какой-то 20-летний тимлид. :-)
Как чем? Домашние дела, уборка, готовка, уроки с ребёнком делать, кружки там всякие. Ближе к полуночи свалиться без сил в кровать, там есть секунд 10 на подумать "как можно было бы отдохнуть" и вырубиться до будильника в 6 утра.
Прекрасный вывод в каждой из проблем, как и заключение: если не получается - увольняйтесь. :-)
Был свидетелем интересной ситуации в коллективе, в котором царила достаточно мрачная обстановка (я только пришёл туда работать) - через 2 недели увольняется ведущий сотрудник и внезапно все расцветают! Оказывается ведущий и был гнетущим фактором. К слову, за 15 лет трудовой деятельности это оказался самый лучший коллектив, в котором мне приходилось работать.
Начнём с хорошего. :-) Сам чек-лист полезный, если по уму разобрать каждый пункт, а не удостовериться, что оно просто есть.
По тексту - местами кажется неплохо (там где чисто про разработку, типа баттлов в MR и диаграммы классов), ибо я в этом не силён, а вот остальное...
Вы скорее всего непосредственно в разработке крутитесь и дальше только видели со стороны и возможно выцепили несколько слов/определений из статей (не факт, что грамотных), ибо в разрезах управления проектами, командами, процессами и прочим, что не связано напрямую с написанием кода, мягко говоря, "плывёте".
И отдельно не стоило начинать статью, надевая на себя корону бакалавра с 6-летним опытом в вэбе.
Статья, конечно, рекламная чуть менее, чем полностью. Хотелось бы увидеть разбор решённых при разработке проблем или сложности, над которыми поломали голову и нашли изящное решение.
У нас лет 7 назад был проект, только по продаже недвижимости. Админка ну очень похожа, тоже на бэке, правда там Yii 2.
Выкладывайте всё, что запланировали, без спроса. Ведь скорее всего именно вместе, составив цикл статей, они обретут гораздо большую ценность в виду комплексного охвата проблематики тимлидства.
И обязательно делайте ссылки в каждой статье на предыдущие и следующие, это и вам, как автору, увеличит просмотры, а главное - читателям будет больший простор для получения новой информации.
Не сомневаюсь, что у лидера DaaS сегмента имеются ценности и процессы, но всё, что увидел в статье - шаблонные фразы с крайне скудным количеством примеров и без уточнений вглубь. А хотелось бы именно разбора по каждому пункту, пусть и в отдельной статье на пункт.
В текущем виде статья похожа на рекламный проспект для клиентов и потенциальных работников с девизом "Мир, дружба, DevOps".
кейс остается в статусе review до того момента, пока все замечания не будут исправлены
Непрозрачный момент. Кто-то должен актуализировать реальный статус (проверяется или на доработке). Нагляднее было бы вернуть в draft или отдельный статус, ибо draft тоже имеет под собой пару статусов - "древний черновик на когда-нибудь" или "свежий кейс в работе, скоро будет готов". Поднимите этот вопрос с командой. Когда приработались, кажется, что нормально, а со стороны видны "терра инкогнита" на вашем воркфлоу.
Дежурство у нас понедельное. Каждую неделю ребята смотрят все упавшие тесты.
На совсем понятно, как реализовано дежурство, если 3 модуля и 3 автоматчика. У каждого автоматчика свой модуль? Тогда он всегда на дежурстве. Каждую неделю только 1 автоматчик дежурит, а двое работают по текущим задачам? Почему все сейчас не кидаются вместе одно и то же чинить? Раньше они втроём видели алерт и одновременно независимо друг от друга садились за него? Тут в помощь назначение ответственного за алерт. Кто-то зашёл, выбрал себя (или дежурный его назначил), и вся команда видит, кто работает с алертом и его уже трогать не надо.
Статья полезная, спасибо! Но ещё в самом начале глаз зацепился за фразу и обронил суровую слезу.
Какой-то 20-летний тимлид. :-)
Как чем? Домашние дела, уборка, готовка, уроки с ребёнком делать, кружки там всякие. Ближе к полуночи свалиться без сил в кровать, там есть секунд 10 на подумать "как можно было бы отдохнуть" и вырубиться до будильника в 6 утра.
Прекрасный вывод в каждой из проблем, как и заключение: если не получается - увольняйтесь. :-)
Был свидетелем интересной ситуации в коллективе, в котором царила достаточно мрачная обстановка (я только пришёл туда работать) - через 2 недели увольняется ведущий сотрудник и внезапно все расцветают! Оказывается ведущий и был гнетущим фактором. К слову, за 15 лет трудовой деятельности это оказался самый лучший коллектив, в котором мне приходилось работать.
Начнём с хорошего. :-) Сам чек-лист полезный, если по уму разобрать каждый пункт, а не удостовериться, что оно просто есть.
По тексту - местами кажется неплохо (там где чисто про разработку, типа баттлов в MR и диаграммы классов), ибо я в этом не силён, а вот остальное...
Вы скорее всего непосредственно в разработке крутитесь и дальше только видели со стороны и возможно выцепили несколько слов/определений из статей (не факт, что грамотных), ибо в разрезах управления проектами, командами, процессами и прочим, что не связано напрямую с написанием кода, мягко говоря, "плывёте".
И отдельно не стоило начинать статью, надевая на себя корону бакалавра с 6-летним опытом в вэбе.
Ну так себе статистика для компании со штатом 5000+ человек. Топы отметились, рабам на галерах не до этого. :-)
В последней картинке нижнюю строку исправьте, пожалуйста.
Подозреваю, что в простом проекте, как новой, так и зрелой командам можно обойтись без аналитика, судя по тексту статьи.
Статья, конечно, рекламная чуть менее, чем полностью. Хотелось бы увидеть разбор решённых при разработке проблем или сложности, над которыми поломали голову и нашли изящное решение.
У нас лет 7 назад был проект, только по продаже недвижимости. Админка ну очень похожа, тоже на бэке, правда там Yii 2.
Хорошая статья, полезная.
Выкладывайте всё, что запланировали, без спроса. Ведь скорее всего именно вместе, составив цикл статей, они обретут гораздо большую ценность в виду комплексного охвата проблематики тимлидства.
И обязательно делайте ссылки в каждой статье на предыдущие и следующие, это и вам, как автору, увеличит просмотры, а главное - читателям будет больший простор для получения новой информации.
Моё почтение!
Не сомневаюсь, что у лидера DaaS сегмента имеются ценности и процессы, но всё, что увидел в статье - шаблонные фразы с крайне скудным количеством примеров и без уточнений вглубь. А хотелось бы именно разбора по каждому пункту, пусть и в отдельной статье на пункт.
В текущем виде статья похожа на рекламный проспект для клиентов и потенциальных работников с девизом "Мир, дружба, DevOps".
Спасибо за опыт! Верной дорогой идёте.
Непрозрачный момент. Кто-то должен актуализировать реальный статус (проверяется или на доработке). Нагляднее было бы вернуть в draft или отдельный статус, ибо draft тоже имеет под собой пару статусов - "древний черновик на когда-нибудь" или "свежий кейс в работе, скоро будет готов". Поднимите этот вопрос с командой. Когда приработались, кажется, что нормально, а со стороны видны "терра инкогнита" на вашем воркфлоу.
На совсем понятно, как реализовано дежурство, если 3 модуля и 3 автоматчика.
У каждого автоматчика свой модуль? Тогда он всегда на дежурстве.
Каждую неделю только 1 автоматчик дежурит, а двое работают по текущим задачам?
Почему все сейчас не кидаются вместе одно и то же чинить? Раньше они втроём видели алерт и одновременно независимо друг от друга садились за него? Тут в помощь назначение ответственного за алерт. Кто-то зашёл, выбрал себя (или дежурный его назначил), и вся команда видит, кто работает с алертом и его уже трогать не надо.
Если бы вы рассматривали выгоду не лично для себя себя, как единственного существующего работника на планете, то может и нашли бы.
Хотя что это я, таких комментаторов в интернетах полно: "раз мне не нравится, значит это какая-то ерунда недостойная существования".
Editor.js не всё поддерживает в плане форматирования, как заявлено. Плюсом какие-то плюшки, которые есть в сообществе, не работают.
Если вы в нём хотите только h, ol/il, b/u/i использовать, то хватит. А что-то сложное, типа видео из youtube, то лучше другой инструмент поискать.