G
С какого перепугу-то? Или руководитель у тебя это синий воротничок онли?
Size: a a a
2020 October 16
К
уверены, что хотите знать насколько глубока кроличья нора?
Да :)
A
Ну так-то да. Я к тому и веду, что (если не натягивать сову на глобус) девопёсы это системные инженеры. Со своей градацией. От начинающего до архитектора.
Переделая немного извесный текст:
Джун - не самостоятельный. За ним проверяют решения/работы. Делает простые вещи сложными путями. Сложные не делает.
Миддл - самостоятельный. Проверять за ним не обязательно, только разбирать на ревью очередные неоптимальные решения. Простые вещи делает простыми путями, сложные сложными.
Сеньор - немного управленец. Ревьюит мидлов. Сложные вещи делает простыми путями, простые не делает.
Вот последняя градация и есть архитектор. Задаёт общую архитектуру совместно с другими лидами/архитекторами/техдирами и имеет огого экспертизу, как лучше делать в той или иной ситуации.
Переделая немного извесный текст:
Джун - не самостоятельный. За ним проверяют решения/работы. Делает простые вещи сложными путями. Сложные не делает.
Миддл - самостоятельный. Проверять за ним не обязательно, только разбирать на ревью очередные неоптимальные решения. Простые вещи делает простыми путями, сложные сложными.
Сеньор - немного управленец. Ревьюит мидлов. Сложные вещи делает простыми путями, простые не делает.
Вот последняя градация и есть архитектор. Задаёт общую архитектуру совместно с другими лидами/архитекторами/техдирами и имеет огого экспертизу, как лучше делать в той или иной ситуации.
Начнем с того, что девопсы, это название которые используют люди, которые не знают что такое DevOps в принципе. И для начала дискуссии необходимо определиться с тем, что же такое DevOps. Иными словами, сначала нужно обозначить объект дискуссии, а только потом переходить к его субъекту.
Итак, DevOps, как объект это в первую очередь философия разработки продукта. Не роль, должность, название отдела, а именно философия и, если Вы откроете манифест объекта прочтете все сами.
Почему-то манифест Agile все читают, а DevOps нет, но это лирика.
Итак, определившись с объектом переходим к его субъекту. Субъектом будет SRE (GOOGLE: class SRE implements DevOps). В рамках своих прямых обязанностей, на самом примитивном уровне, можно определить несколько выполняемых задач:
- Проектирование и построение архитектуры проекта (здесь имеется ввиду и пресловутый CI/CD и сама архитектура того же k8s фреймворка)
- Написание оптимизационных скриптов и написание небольших программ ввиде операторов
- Создание, поддержка, оптимизация всего flow разработки от коммита, до релиза
Если же мы взглянем на задачи инженера, к которому Вы так все тяготеете, то там кроме настройки софта ничего нет.
Итак, DevOps, как объект это в первую очередь философия разработки продукта. Не роль, должность, название отдела, а именно философия и, если Вы откроете манифест объекта прочтете все сами.
Почему-то манифест Agile все читают, а DevOps нет, но это лирика.
Итак, определившись с объектом переходим к его субъекту. Субъектом будет SRE (GOOGLE: class SRE implements DevOps). В рамках своих прямых обязанностей, на самом примитивном уровне, можно определить несколько выполняемых задач:
- Проектирование и построение архитектуры проекта (здесь имеется ввиду и пресловутый CI/CD и сама архитектура того же k8s фреймворка)
- Написание оптимизационных скриптов и написание небольших программ ввиде операторов
- Создание, поддержка, оптимизация всего flow разработки от коммита, до релиза
Если же мы взглянем на задачи инженера, к которому Вы так все тяготеете, то там кроме настройки софта ничего нет.
АМ
Лид управляет командой с технической стороны, раскидывает таски, решает какой говнокод вы будете писать сегодня. Руководитель это административная часть, общение с отделами, согласования, etc
MO
есть третий, там про бухло и прочее. вот там такие темы зайдут на ура. там даже матерится можно
Так сколько всего про бухло?
A
Лид управляет командой с технической стороны, раскидывает таски, решает какой говнокод вы будете писать сегодня. Руководитель это административная часть, общение с отделами, согласования, etc
+
A
Лид управляет командой с технической стороны, раскидывает таски, решает какой говнокод вы будете писать сегодня. Руководитель это административная часть, общение с отделами, согласования, etc
Up читай мой
АМ
Начнем с того, что девопсы, это название которые используют люди, которые не знают что такое DevOps в принципе. И для начала дискуссии необходимо определиться с тем, что же такое DevOps. Иными словами, сначала нужно обозначить объект дискуссии, а только потом переходить к его субъекту.
Итак, DevOps, как объект это в первую очередь философия разработки продукта. Не роль, должность, название отдела, а именно философия и, если Вы откроете манифест объекта прочтете все сами.
Почему-то манифест Agile все читают, а DevOps нет, но это лирика.
Итак, определившись с объектом переходим к его субъекту. Субъектом будет SRE (GOOGLE: class SRE implements DevOps). В рамках своих прямых обязанностей, на самом примитивном уровне, можно определить несколько выполняемых задач:
- Проектирование и построение архитектуры проекта (здесь имеется ввиду и пресловутый CI/CD и сама архитектура того же k8s фреймворка)
- Написание оптимизационных скриптов и написание небольших программ ввиде операторов
- Создание, поддержка, оптимизация всего flow разработки от коммита, до релиза
Если же мы взглянем на задачи инженера, к которому Вы так все тяготеете, то там кроме настройки софта ничего нет.
Итак, DevOps, как объект это в первую очередь философия разработки продукта. Не роль, должность, название отдела, а именно философия и, если Вы откроете манифест объекта прочтете все сами.
Почему-то манифест Agile все читают, а DevOps нет, но это лирика.
Итак, определившись с объектом переходим к его субъекту. Субъектом будет SRE (GOOGLE: class SRE implements DevOps). В рамках своих прямых обязанностей, на самом примитивном уровне, можно определить несколько выполняемых задач:
- Проектирование и построение архитектуры проекта (здесь имеется ввиду и пресловутый CI/CD и сама архитектура того же k8s фреймворка)
- Написание оптимизационных скриптов и написание небольших программ ввиде операторов
- Создание, поддержка, оптимизация всего flow разработки от коммита, до релиза
Если же мы взглянем на задачи инженера, к которому Вы так все тяготеете, то там кроме настройки софта ничего нет.
Честно говоря официальный манифест DevOps написан как говно
MO
Да :)
Что предложите взамен ?
АМ
Его там переописывали на примере Agile
A
Честно говоря официальный манифест DevOps написан как говно
Открой по Agile/ITIL/ITSM увидишь тоже самое
АМ
Но вот если брать офишал, то там будто я таску в жиру писал
A
Но вот если брать офишал, то там будто я таску в жиру писал
Всяко лучше агила описано ;D на мой взгляд, намного понятнее
A
Лид управляет командой с технической стороны, раскидывает таски, решает какой говнокод вы будете писать сегодня. Руководитель это административная часть, общение с отделами, согласования, etc
А что таски без лида не раскидаются?
Sf
А иногда таски раскидывают лида
Sf
И лид сыпется
A
А что таски без лида не раскидаются?
Есть золотая середина управления, 1 к 3. Т.е ты один можешь в полной мере рулить 3 человеками без потери КПД. когда у тебя становится 3+1 сотрудников, уже нужно нанимать промежуточное звено, которое будет выполнять твои старые задачи, но без потери КПД.
Таким образом и появился тех.лид, которые просто отвечает за группу людей и раскидывает задачи и помогает в сложных местах
Таким образом и появился тех.лид, которые просто отвечает за группу людей и раскидывает задачи и помогает в сложных местах
Н
Есть золотая середина управления, 1 к 3. Т.е ты один можешь в полной мере рулить 3 человеками без потери КПД. когда у тебя становится 3+1 сотрудников, уже нужно нанимать промежуточное звено, которое будет выполнять твои старые задачи, но без потери КПД.
Таким образом и появился тех.лид, которые просто отвечает за группу людей и раскидывает задачи и помогает в сложных местах
Таким образом и появился тех.лид, которые просто отвечает за группу людей и раскидывает задачи и помогает в сложных местах
зависит от вовлеченности и кучи других факторов, 1/3 это уже микроменеджмент какой-то
A
зависит от вовлеченности и кучи других факторов, 1/3 это уже микроменеджмент какой-то
Ну вот у тебя свои задачи, а тебе ревью еще делать, помогать и обучать. Больше 3х ты просто не вытянешь, проверено практикой
G
Начнем с того, что девопсы, это название которые используют люди, которые не знают что такое DevOps в принципе. И для начала дискуссии необходимо определиться с тем, что же такое DevOps. Иными словами, сначала нужно обозначить объект дискуссии, а только потом переходить к его субъекту.
Итак, DevOps, как объект это в первую очередь философия разработки продукта. Не роль, должность, название отдела, а именно философия и, если Вы откроете манифест объекта прочтете все сами.
Почему-то манифест Agile все читают, а DevOps нет, но это лирика.
Итак, определившись с объектом переходим к его субъекту. Субъектом будет SRE (GOOGLE: class SRE implements DevOps). В рамках своих прямых обязанностей, на самом примитивном уровне, можно определить несколько выполняемых задач:
- Проектирование и построение архитектуры проекта (здесь имеется ввиду и пресловутый CI/CD и сама архитектура того же k8s фреймворка)
- Написание оптимизационных скриптов и написание небольших программ ввиде операторов
- Создание, поддержка, оптимизация всего flow разработки от коммита, до релиза
Если же мы взглянем на задачи инженера, к которому Вы так все тяготеете, то там кроме настройки софта ничего нет.
Итак, DevOps, как объект это в первую очередь философия разработки продукта. Не роль, должность, название отдела, а именно философия и, если Вы откроете манифест объекта прочтете все сами.
Почему-то манифест Agile все читают, а DevOps нет, но это лирика.
Итак, определившись с объектом переходим к его субъекту. Субъектом будет SRE (GOOGLE: class SRE implements DevOps). В рамках своих прямых обязанностей, на самом примитивном уровне, можно определить несколько выполняемых задач:
- Проектирование и построение архитектуры проекта (здесь имеется ввиду и пресловутый CI/CD и сама архитектура того же k8s фреймворка)
- Написание оптимизационных скриптов и написание небольших программ ввиде операторов
- Создание, поддержка, оптимизация всего flow разработки от коммита, до релиза
Если же мы взглянем на задачи инженера, к которому Вы так все тяготеете, то там кроме настройки софта ничего нет.
Начнём с того, что гугловский SRE изначально мёртворождённая херня. Это любое ООО может родить себе "держателя пёсьего хвоста второго ранга", написать ему должностную инструкцию и определить круг задач. За пределами этого ООО данная должность работать не будет.
Так что и их трактование "инженера как настройщика софта" (это является администрированием так-то) тоже не жизненоспособна.
Закончим тем, что инженер - понятие общее. Системный инженер, это инженер по системам. В том числе по системам сборки/доставки кода. Так что я не тяготею к нему, а называю вещи своими именами. Не придумывая на ходу кучу сущностей.
Так что и их трактование "инженера как настройщика софта" (это является администрированием так-то) тоже не жизненоспособна.
Закончим тем, что инженер - понятие общее. Системный инженер, это инженер по системам. В том числе по системам сборки/доставки кода. Так что я не тяготею к нему, а называю вещи своими именами. Не придумывая на ходу кучу сущностей.