Самая полезная практика совещаний — постараться обойтись без совещаний. Совещание — это синхронное действие. А в современном динамичном мире, где задачи возникают внезапно и непредсказуемо, рулит асинхронность.
Пооэтому, в порядке предпочтения, задачу желательно решить:
Сообщением в мессенджер (личным или в чат). Желательно, чтобы это был короткий вопрос, на который можно ответить «да/нет», либо четкая постановка простой задачи «по smart».
Письмом на электронную почту. Хорошо работает, когда нужно, например, согласовать документ: «Всем привет, проект договора готов, если есть замечания — пришлите до завтра 9:00, иначе — подписываем в этом варианте». Для мира разработки ПО вместо переписки по почте целесообразно провести code review средствами системы контроля версий.
Звонком или беседой «один на один» — если а) нужно срочно, и б) решение вопроса предполагает обсуждение в форме диалога. Пример — снять присланное замечание к документу, которое непонятно. Или решить, как можно доработать код по замечанию, полученному на code review.
Не все задачи решаются перечисленными способами. Совещание обязательно нужно собирать, когда люди а) не могут договориться б) не в контексте. В этом случае, да, хорошо работают перечисленные практики — повестка, фиксация договоренностей, и обязательно — модерация. Иначе присутствующие NNN человек внезапно обнаружат, что время истекает, а вопросы решены от силы на четверть.
Есть на работе T410 2010 года, в свое время добавил памяти до 8 Гб, поставил диск SSD, проапгрейдил windows до 10. Хорошая лошадка, до сих пор полезная в хозяйстве.
Единственная претензия — wifi с поддержкой только 2.4 ГГц, 802.11n и без современных наворотов. Его тоже можно поменять, но как-то руки не доходят.
Ну автор в статье упоминал канбан, я так понял, ему «зашло». Диаграмма Ганта — она скорее для оценки времени выполнения целого проекта или большого этапа проекта, а канбан — для структурирования входящих запросов и выстраивания приоритетов.
Мутная задача — прежде всего плохо поставленная задача. Разделить её на понятные, т. е. которые можно делегировать подчинённым «по S.M.A.R.T.» — это и есть задача тимлида. Парадокс, но иногда для этого надо немного покодить :)
По п. 1 — кодить всё равно приходится, но нужно брать только те задачи, которые невозможно делегировать. Как правило, это самые «мутные», плохо сформулированные задачи. Как только задача стала яснее (например, её удалось декомпозировать) — нужно постараться сразу отдать хотя бы часть.
По п. 2 — есть примерно такая формулировка: «Инструменты разработчика — компилятор, IDE, линтер и т. п., инструменты тимлида — прежде всего другие разработчики, а потом уже компилятор, IDE, линтер и т. п.». Музыканты ещё говорят, что дирижёр — это такой музыкант, который играет «на оркестре».
По п. 3 — планирование всегда больной вопрос. Во-первых, на планирование надо выделять отдельное время. Например, полчаса с утра для того чтобы подвигать задачи на своей личной канбан-доске. Во-вторых, рекомендация для других людей «планировать встречи, глядя в ваш календарь» — очень спорная. К сожалению, некоторые коллеги страдают болезнью «скучно? собери совещание!», и ты вдруг понимаешь, что у тебя вообще весь календарь расписан какими-то непонятными встречами. И поэтому в-третьих, следует приучить коллег, что вопросы надо решать в порядке приоритета - коротким сообщением в мессенджер, письмом, звонком, и если только не получается договориться - собирать совещание.
В порядке обмена опытом — если задачи не выстраиваются «друг за другом», т. е. их взанимное влияние неочевидно, вместо канбана (или в дополнение) хороша техника «ментальных карт» (mind maps). Особенно полезна при сложных миграциях, где надо обеспечить непрерывность сервиса.
По п. 4 — да, всё так, стоит тимлиду расслабиться, и проектная команда начинает вешать на него принятие всех мелких и не очень мелких решений. Нужно уметь «возвращать» вопрос, т. е. спрашивать «а что бы сделал ты? а почему так? а какие вообще ты здесь видишь варианты? какие из них лучше?» Именно так сотрудники и развиваются. Также нужно учить сотрудников «не держать информацию в себе» — сообщать тимлиду о проблемах — немедленно, другим участникам проекта — какие решения приняты и почему.
Цель же не в том, чтобы «прессовать» — цель в том, чтобы за один час собеседования приблизительно понять, что человек умеет, чему его придется учить, сколько времени займет обучение, и чему он в результате научится быстро, а чему — будет учиться долго или не научится никогда, как-то так.
Я в общем тоже наверное хороший полицейский (стараюсь быть, кандидатам виднее).
Страхи отчасти обоснованны — почти никто в институте и на работе целенаправленно не учит теорию, не копит теоретические знания, не складывает специально их в систему. Студенты к экзамену учат «билеты». Те, кто уже работает, доводят до совершенства навыки, нужные именно на данной работе, и изо дня в день их успешно применяют, максимально избагая рабочего стресса.
На собеседовании картина меняется. Потенциальному работодателю важно, насколько быстро и успешно кандидат вольётся в проект и возьмёт на себя часть задач. На этом этапе у нового работника точно возникнет стресс, и реакцию на этот стресс хорошо бы увидеть уже на собеседовании. Так что потенциальный руководитель будет всегда «копать в глубину» и пытаться найти вопрос, на который кандидат не ответит, это важно уже для его карьеры.
Надо сказать, что собеседующие тоже не всегда демонстрируют лучшие качества — например, не пытаются выслушать и проанализировать ответы кандидата, а пытаются уложить эти ответы в ими же придуманную псевдо-идеальную картину.
Хорошая книга. В свое время именно в ней я нешёл ответ на вопрос «почему продукты компании Микрософт вроде бы всем хороши, но их использование не приносит радости». Рекомендую прочитать ее не только специалистам по UI/UX, но и программистам (чтобы разрабатывать хорошие API), безопасникам (чтобы разрабатывать хорошие политики ИБ), да и вообще всем, кто хочет делать жизнь людей удобнее.
Нужно превратить этот вопрос в "как позвать на курсы тех, кому оно надо"
Можно поставить вопрос ещё шире — например, «как принять на работу тех, кто будет хорошо работать». Пока наша концепция (для начинающих специалистов) — чтобы был интерес к тому, чем мы занимаемся (и к ИТ в принципе). Остальному можно научить и научиться.
На «каких-то курсах» научиться «нормально» нельзя ничему — здесь задача осуществить bootstrap и показать направление, куда двигаться (это вообще любых курсов касается).
Верно и обратное — те сотрудники, которым можно показать направление, и они сами начинают в том направлении идти, быстрее всех прогрессируют, и очень ценятся работодателями.
А дальше 2 варианта - либо человек сидит и использует только стандартные заученные конструкции в коде и не может ничего толком написать (зачем ему тогда пайтон, если конструкции в ансибле запомнить проще?)
Это вообще самый сложный вопрос подготовки (и самоподготовки) любого специалиста — как сделать так, чтобы знания сложились в систему. Здесь нет однозначного ответа (за годы преподавательского опыта я его так и не нашел). Мне кажется, что нужные нейронные связи будущий специалист может сформировать только сам — пробуя, ошибаясь, размышляя, и берясь за всё более сложные задачи. Это стресс, это боль, но пойти по «простому» пути (годами использовать стандартные конструкции для решения стандартных задач) — тоже невесело, и ценность такого специалиста будет со временем падать.
Про shell и ansible — всё так и есть, а дальше возникают вопросы
можно и нужно показать golang. ... безапялицонно показывать людям python как первый инструмент для автоматизации ops-работы - плохой путь. Это полноценный ЯП
golang я не знаю (видел издали, слышал хорошие отзывы, но ни строчки кода на нём не написал), впечатления от него — это хороший, полнофункциональный язык, особенно для того чтобы быстро и качественно написать backend-часть веб-приложения.
Почему вы его противопоставляете питону, называя питон «полноценным ЯП»? Чем golang менее «полноценен»?
Давайте воспользуемся принципом «критикуешь — предлагай». К питону как к первому языку у меня тоже масса вопросов, но на чём ещё учить? В вузах сейчас учат в основном сразу на несуществующем языке «С/С++» (ибо «индустрия требует»), и ребята приходят к нам уже с психотравмой и стойким отвращением к написанию кода. Идти по пути, предлагаемому Столяровым — методически правильно, но на это нужен плюс-минус год. Какие ещё есть варианты?
Ну точно не про нашу компанию, и не про наше подразделение. У нас скорее другая проблема — когда молодой и очень старательный инженер в текстовом редакторе перепиливает 100500 правил ACL из формата, условно, cisco, в формат, условно, iptables, и пользуется максимум поиском/заменой. Хотя никто не запрещает ни bash, ни awk, ни регулярные выражения, ни perl, ни python.
Статья — попытка начать дискуссию на тему «почему инженер/админ/связист боится/не хочет написать нужный ему по работе кусок кода» и как ему можно помочь (захотеть). Вернее, вынести наши внутренние обсуждения на эти темы на более широкую аудиторию. Готовы об этом поговорить?
Спасибо за развернутый комментарий. Да, мы с помощью курса пытались решить именно наши задачи. Как получилось — лучше расскажут сами участники обучения (а также те, с кем они вместе работают). По поводу деления наук на «первый и второй уровни» — спорное утверждение. Хорошая вузовская программа предусматривает теорию (лекции, семинары) и практику (лабы, курсовые). Алгоритмы, дискретная математика, теория формальных языков, реляционная алгебра — это теория. А написание кода на конкретном языке — это, конечно же, практика. В наших условиях мы, конечно же, можем дать в основном практику. Теорию — только «по верхам», в расчете, что кто-то заинтересуется и пойдет читать книжки.
У Cisco есть ISE, но к нему — масса вопросов. Управление политиками там реализовано, мягко говоря, своеобразно.Мы были в похожей ситуации, и дело кончилось заменой VPN-решения. Вообще же, etnerprise-подход должен выглядеть так: помещаем пользователей в группы AD, и далее все VPN-шлюзы сами на основе членства в группах формируют при подключении пользователя персональные политики доступа. Связка ASA+ISE, PaloAlto, Fortinet — умеют такое в каком-то виде, но, как всегда, «не совсем так как хочется».
На самом деле, поднятая в статье проблема очень серьёзная. Работники обычно а) не идиоты б) любят деньги, поэтому если им установить KPI — они будут добросовестно исполнять KPI.
Если в результате такого добросовестного исполнения получается полная фигня — далеко не каждый руководитель сможет решить проблему и грамотно скорректировать показатели. Бывают и такие, которые отказываются признать, что проблема вообще существует, увы.
> Чем вам Керниган-Ритчи и Си как первый язык для обучения основам не угодил.
Строгий «академический» ответ на этот вопрос приведен в монографии Столярова, ссылку на которую дали в комментах выше.
А я по-простому скажу. Си похож одновременно на самурайский меч, турецкую саблю и мушкетёрскую шпагу — устроен очень просто, в нём почти ничего нет, но приёмы написания программ на нём — сложны и замысловаты. И для освоения именно этих приёмов (и безопасного их применения!) нужно много специальных знаний.
Таким образом, изучение Си на уровне чуть выше элементарного тут же превращатся в изучение операционной системы (что такое файл? а дескриптор файла? И зачем функция dup2?), архитектуры компьютера (ошибки buffer overflow где-то рядом, а вместе с ними — опасные уязвимости) и прочих интересных вещей. Такие знания, разумеется, программисту тоже нужны, но на самом начальном этапе обучения программированию у студента начинается информационный перегруз — он не в состоянии справиться с потоком сведений и отделить важное от неважного, как, собственно, и произошло с автором исходного поста.
Самая полезная практика совещаний — постараться обойтись без совещаний. Совещание — это синхронное действие. А в современном динамичном мире, где задачи возникают внезапно и непредсказуемо, рулит асинхронность.
Пооэтому, в порядке предпочтения, задачу желательно решить:
Сообщением в мессенджер (личным или в чат). Желательно, чтобы это был короткий вопрос, на который можно ответить «да/нет», либо четкая постановка простой задачи «по smart».
Письмом на электронную почту. Хорошо работает, когда нужно, например, согласовать документ: «Всем привет, проект договора готов, если есть замечания — пришлите до завтра 9:00, иначе — подписываем в этом варианте». Для мира разработки ПО вместо переписки по почте целесообразно провести code review средствами системы контроля версий.
Звонком или беседой «один на один» — если а) нужно срочно, и б) решение вопроса предполагает обсуждение в форме диалога. Пример — снять присланное замечание к документу, которое непонятно. Или решить, как можно доработать код по замечанию, полученному на code review.
Не все задачи решаются перечисленными способами. Совещание обязательно нужно собирать, когда люди а) не могут договориться б) не в контексте. В этом случае, да, хорошо работают перечисленные практики — повестка, фиксация договоренностей, и обязательно — модерация. Иначе присутствующие NNN человек внезапно обнаружат, что время истекает, а вопросы решены от силы на четверть.
Есть на работе T410 2010 года, в свое время добавил памяти до 8 Гб, поставил диск SSD, проапгрейдил windows до 10. Хорошая лошадка, до сих пор полезная в хозяйстве.
Единственная претензия — wifi с поддержкой только 2.4 ГГц, 802.11n и без современных наворотов. Его тоже можно поменять, но как-то руки не доходят.
Ну автор в статье упоминал канбан, я так понял, ему «зашло». Диаграмма Ганта — она скорее для оценки времени выполнения целого проекта или большого этапа проекта, а канбан — для структурирования входящих запросов и выстраивания приоритетов.
Мутная задача — прежде всего плохо поставленная задача. Разделить её на понятные, т. е. которые можно делегировать подчинённым «по S.M.A.R.T.» — это и есть задача тимлида. Парадокс, но иногда для этого надо немного покодить :)
Очень хорошо всё расписано, немного дополню.
По п. 1 — кодить всё равно приходится, но нужно брать только те задачи, которые невозможно делегировать. Как правило, это самые «мутные», плохо сформулированные задачи. Как только задача стала яснее (например, её удалось декомпозировать) — нужно постараться сразу отдать хотя бы часть.
По п. 2 — есть примерно такая формулировка: «Инструменты разработчика — компилятор, IDE, линтер и т. п., инструменты тимлида — прежде всего другие разработчики, а потом уже компилятор, IDE, линтер и т. п.». Музыканты ещё говорят, что дирижёр — это такой музыкант, который играет «на оркестре».
По п. 3 — планирование всегда больной вопрос. Во-первых, на планирование надо выделять отдельное время. Например, полчаса с утра для того чтобы подвигать задачи на своей личной канбан-доске. Во-вторых, рекомендация для других людей «планировать встречи, глядя в ваш календарь» — очень спорная. К сожалению, некоторые коллеги страдают болезнью «скучно? собери совещание!», и ты вдруг понимаешь, что у тебя вообще весь календарь расписан какими-то непонятными встречами. И поэтому в-третьих, следует приучить коллег, что вопросы надо решать в порядке приоритета - коротким сообщением в мессенджер, письмом, звонком, и если только не получается договориться - собирать совещание.
В порядке обмена опытом — если задачи не выстраиваются «друг за другом», т. е. их взанимное влияние неочевидно, вместо канбана (или в дополнение) хороша техника «ментальных карт» (mind maps). Особенно полезна при сложных миграциях, где надо обеспечить непрерывность сервиса.
По п. 4 — да, всё так, стоит тимлиду расслабиться, и проектная команда начинает вешать на него принятие всех мелких и не очень мелких решений. Нужно уметь «возвращать» вопрос, т. е. спрашивать «а что бы сделал ты? а почему так? а какие вообще ты здесь видишь варианты? какие из них лучше?» Именно так сотрудники и развиваются. Также нужно учить сотрудников «не держать информацию в себе» — сообщать тимлиду о проблемах — немедленно, другим участникам проекта — какие решения приняты и почему.
Цель же не в том, чтобы «прессовать» — цель в том, чтобы за один час собеседования приблизительно понять, что человек умеет, чему его придется учить, сколько времени займет обучение, и чему он в результате научится быстро, а чему — будет учиться долго или не научится никогда, как-то так.
Я в общем тоже наверное хороший полицейский (стараюсь быть, кандидатам виднее).
Страхи отчасти обоснованны — почти никто в институте и на работе целенаправленно не учит теорию, не копит теоретические знания, не складывает специально их в систему. Студенты к экзамену учат «билеты». Те, кто уже работает, доводят до совершенства навыки, нужные именно на данной работе, и изо дня в день их успешно применяют, максимально избагая рабочего стресса.
На собеседовании картина меняется. Потенциальному работодателю важно, насколько быстро и успешно кандидат вольётся в проект и возьмёт на себя часть задач. На этом этапе у нового работника точно возникнет стресс, и реакцию на этот стресс хорошо бы увидеть уже на собеседовании. Так что потенциальный руководитель будет всегда «копать в глубину» и пытаться найти вопрос, на который кандидат не ответит, это важно уже для его карьеры.
Надо сказать, что собеседующие тоже не всегда демонстрируют лучшие качества — например, не пытаются выслушать и проанализировать ответы кандидата, а пытаются уложить эти ответы в ими же придуманную псевдо-идеальную картину.
Хорошая книга. В свое время именно в ней я нешёл ответ на вопрос «почему продукты компании Микрософт вроде бы всем хороши, но их использование не приносит радости».
Рекомендую прочитать ее не только специалистам по UI/UX, но и программистам (чтобы разрабатывать хорошие API), безопасникам (чтобы разрабатывать хорошие политики ИБ), да и вообще всем, кто хочет делать жизнь людей удобнее.
Можно поставить вопрос ещё шире — например, «как принять на работу тех, кто будет хорошо работать». Пока наша концепция (для начинающих специалистов) — чтобы был интерес к тому, чем мы занимаемся (и к ИТ в принципе). Остальному можно научить и научиться.
На «каких-то курсах» научиться «нормально» нельзя ничему — здесь задача осуществить bootstrap и показать направление, куда двигаться (это вообще любых курсов касается).
Верно и обратное — те сотрудники, которым можно показать направление, и они сами начинают в том направлении идти, быстрее всех прогрессируют, и очень ценятся работодателями.
Это вообще самый сложный вопрос подготовки (и самоподготовки) любого специалиста — как сделать так, чтобы знания сложились в систему. Здесь нет однозначного ответа (за годы преподавательского опыта я его так и не нашел). Мне кажется, что нужные нейронные связи будущий специалист может сформировать только сам — пробуя, ошибаясь, размышляя, и берясь за всё более сложные задачи. Это стресс, это боль, но пойти по «простому» пути (годами использовать стандартные конструкции для решения стандартных задач) — тоже невесело, и ценность такого специалиста будет со временем падать.
Про shell и ansible — всё так и есть, а дальше возникают вопросы
golang я не знаю (видел издали, слышал хорошие отзывы, но ни строчки кода на нём не написал), впечатления от него — это хороший, полнофункциональный язык, особенно для того чтобы быстро и качественно написать backend-часть веб-приложения.
Почему вы его противопоставляете питону, называя питон «полноценным ЯП»? Чем golang менее «полноценен»?
Давайте воспользуемся принципом «критикуешь — предлагай». К питону как к первому языку у меня тоже масса вопросов, но на чём ещё учить?
В вузах сейчас учат в основном сразу на несуществующем языке «С/С++» (ибо «индустрия требует»), и ребята приходят к нам уже с психотравмой и стойким отвращением к написанию кода.
Идти по пути, предлагаемому Столяровым — методически правильно, но на это нужен плюс-минус год.
Какие ещё есть варианты?
Ну точно не про нашу компанию, и не про наше подразделение. У нас скорее другая проблема — когда молодой и очень старательный инженер в текстовом редакторе перепиливает 100500 правил ACL из формата, условно, cisco, в формат, условно, iptables, и пользуется максимум поиском/заменой. Хотя никто не запрещает ни bash, ни awk, ни регулярные выражения, ни perl, ни python.
Статья — попытка начать дискуссию на тему «почему инженер/админ/связист боится/не хочет написать нужный ему по работе кусок кода» и как ему можно помочь (захотеть). Вернее, вынести наши внутренние обсуждения на эти темы на более широкую аудиторию. Готовы об этом поговорить?
В нашей местной... в чём, простите? Расшифруйте, пожалуйста :)
Спасибо за развернутый комментарий. Да, мы с помощью курса пытались решить именно наши задачи. Как получилось — лучше расскажут сами участники обучения (а также те, с кем они вместе работают).
По поводу деления наук на «первый и второй уровни» — спорное утверждение. Хорошая вузовская программа предусматривает теорию (лекции, семинары) и практику (лабы, курсовые). Алгоритмы, дискретная математика, теория формальных языков, реляционная алгебра — это теория. А написание кода на конкретном языке — это, конечно же, практика.
В наших условиях мы, конечно же, можем дать в основном практику. Теорию — только «по верхам», в расчете, что кто-то заинтересуется и пойдет читать книжки.
В версии, по-моему, 2.3 — умел, к версии 2.4 — сломали. Актуальная версия 3.x, починили ли в ней — не знаю.
У Cisco есть ISE, но к нему — масса вопросов. Управление политиками там реализовано, мягко говоря, своеобразно.Мы были в похожей ситуации, и дело кончилось заменой VPN-решения.
Вообще же, etnerprise-подход должен выглядеть так: помещаем пользователей в группы AD, и далее все VPN-шлюзы сами на основе членства в группах формируют при подключении пользователя персональные политики доступа. Связка ASA+ISE, PaloAlto, Fortinet — умеют такое в каком-то виде, но, как всегда, «не совсем так как хочется».
Если в результате такого добросовестного исполнения получается полная фигня — далеко не каждый руководитель сможет решить проблему и грамотно скорректировать показатели. Бывают и такие, которые отказываются признать, что проблема вообще существует, увы.
Строгий «академический» ответ на этот вопрос приведен в монографии Столярова, ссылку на которую дали в комментах выше.
А я по-простому скажу. Си похож одновременно на самурайский меч, турецкую саблю и мушкетёрскую шпагу — устроен очень просто, в нём почти ничего нет, но приёмы написания программ на нём — сложны и замысловаты. И для освоения именно этих приёмов (и безопасного их применения!) нужно много специальных знаний.
Таким образом, изучение Си на уровне чуть выше элементарного тут же превращатся в изучение операционной системы (что такое файл? а дескриптор файла? И зачем функция dup2?), архитектуры компьютера (ошибки buffer overflow где-то рядом, а вместе с ними — опасные уязвимости) и прочих интересных вещей. Такие знания, разумеется, программисту тоже нужны, но на самом начальном этапе обучения программированию у студента начинается информационный перегруз — он не в состоянии справиться с потоком сведений и отделить важное от неважного, как, собственно, и произошло с автором исходного поста.