Поиска тайных знаний о проектах пост
В IT компаниях зачастую используется куча инструментов: трекеры задач, мессенджеры, системы документооборота и многое другое. И, казалось бы, во всех них идет работа, везде что-то фиксируется. Но как только возникают вопросы вида:
При этом самое смешное заключается в том, что информация зачастую есть в компании. Только мало кто знает - где именно. Управленцы работают в одних системах, разработчики каждой команды - в других (иногда даже каждая в своей), дизайнеры - в третьих — и обмена знаниями между ними почти не происходит.
Я уже не первый год сталкиваюсь с такими проблемами и частично научился их решать. И очень хочется поговорить об этом лично, поделиться болью и рецептами.
23 и 24 сентября я буду на конференции Saint TeamLead Conf в Питере. Проведу там митап Поиски тайных знаний о проектах. Постараюсь по итогам выложить заметки в этом канале, но это не точно - обычно оформить разрозненные мысли сложнее всего :) Будете проходить мимо конференции - заглядывайте на огонёк.
В IT компаниях зачастую используется куча инструментов: трекеры задач, мессенджеры, системы документооборота и многое другое. И, казалось бы, во всех них идет работа, везде что-то фиксируется. Но как только возникают вопросы вида:
что это за фича, зачем это сделано?, кто работал над этим? - найти ответы может быть чудовищно трудно.При этом самое смешное заключается в том, что информация зачастую есть в компании. Только мало кто знает - где именно. Управленцы работают в одних системах, разработчики каждой команды - в других (иногда даже каждая в своей), дизайнеры - в третьих — и обмена знаниями между ними почти не происходит.
Я уже не первый год сталкиваюсь с такими проблемами и частично научился их решать. И очень хочется поговорить об этом лично, поделиться болью и рецептами.
23 и 24 сентября я буду на конференции Saint TeamLead Conf в Питере. Проведу там митап Поиски тайных знаний о проектах. Постараюсь по итогам выложить заметки в этом канале, но это не точно - обычно оформить разрозненные мысли сложнее всего :) Будете проходить мимо конференции - заглядывайте на огонёк.
московских митапов пост
Чуть больше чем через неделю в гостях у SkyEng хочу поговорить об управлении знаниями. Про то, как начать, если вы уже что-то попробовали, но ничего не получилось. Про то, что делать, если у вас Confluence, GitLab, Slack и/или ещё пачка других систем, вы пробовали добиваться от людей фиксации знаний, но ничего не получилось. С чего начать? Как продолжить? Что может помочь в этом нелёгком пути?
Участие бесплатное, запись обязательна:
https://rostova-events.timepad.ru/event/1069816/
Чуть больше чем через неделю в гостях у SkyEng хочу поговорить об управлении знаниями. Про то, как начать, если вы уже что-то попробовали, но ничего не получилось. Про то, что делать, если у вас Confluence, GitLab, Slack и/или ещё пачка других систем, вы пробовали добиваться от людей фиксации знаний, но ничего не получилось. С чего начать? Как продолжить? Что может помочь в этом нелёгком пути?
Участие бесплатное, запись обязательна:
https://rostova-events.timepad.ru/event/1069816/
Удалённой работы пост
У компании, в которой я работаю, достаточно уникальный по своим масштабам опыт организации удалённой работы. Более 70 сотрудников в разных концах России и зарубежья и ни одного офиса.
На мой взгляд удалённая работа не сильно отличается от работы в офисе и только ярче подсвечивает проблемы, которые и так есть. Бессмысленные прерывания это боль; противоречивость желаний "заказчиков", находящихся на разных позициях, есть всегда; а проблема планирования и распределения задач, кажется, вообще не может быть решена идеально.
Оформили доклад об этих проблемах и возможных решениях в виде статьи и хорошо смонтированной видеозаписи:
https://habr.com/ru/company/flant/blog/469453/
У компании, в которой я работаю, достаточно уникальный по своим масштабам опыт организации удалённой работы. Более 70 сотрудников в разных концах России и зарубежья и ни одного офиса.
На мой взгляд удалённая работа не сильно отличается от работы в офисе и только ярче подсвечивает проблемы, которые и так есть. Бессмысленные прерывания это боль; противоречивость желаний "заказчиков", находящихся на разных позициях, есть всегда; а проблема планирования и распределения задач, кажется, вообще не может быть решена идеально.
Оформили доклад об этих проблемах и возможных решениях в виде статьи и хорошо смонтированной видеозаписи:
https://habr.com/ru/company/flant/blog/469453/
Хабр
Управление распределенной командой в режиме многопроектности (обзор и видео доклада)
23-24 сентября в Санкт-Петербурге проходила конференция Saint TeamLead Conf 2019 . «Флант» принял в ней активное участие: Игорь Цупко (наш директор по неизвестному) провел митап, на котором участники...
Уютный IT адочек
Поиска тайных знаний о проектах пост В IT компаниях зачастую используется куча инструментов: трекеры задач, мессенджеры, системы документооборота и многое другое. И, казалось бы, во всех них идет работа, везде что-то фиксируется. Но как только возникают вопросы…
На конференции Saint TeamLeadConf удалось пообщаться об управлении знаниями.
Больше всего этой тематикой интересовались тимлиды, руководящие небольшой командой от 5 до 10 человек, в более крупной компании (до 50 человек). Они пробовали что-то документировать, вести вики, но их никто не поддержал. А больше всего их беспокоит невозможность быстро вводить новых сотрудников в курс дела и bus-factor при распределении задач. Если же говорить о платформах, чаще всего люди работают с Gitlab, Google Docs и Jira+Confluence (даже те, кто используют Atlassian стек зачастую предпочитают GitLab 😄 ).
Одним из самых занятных вопросов, который мне задали был: "У нас есть продукт с огромным количеством легаси, разрабатывающийся уже более 5 лет. Никто не знает, почему в продукте сделано то или иное, а что гораздо важее - почему что-то не сделано. Как нам это узнать?". Этот вопрос прекрасен тем, что он противоречит сам себе и здравому смыслу: ничто не поможет вам вспомнить то, чего вы не знаете.
Тем, кто попал в подобную ситуацию можно пожелать сфокусироваться не на упущенном прошлом, но на будущем: что сделать сейчас, чтобы ещё через 5 лет вы так же не страдали о решениях, которые делаются сейчас. Какие организационные решения принять сейчас, чтобы через N месяцев не было bus factor-а при распределении задач, как наиболее простым способом попросить разработчиков оставить чуть больше информации о задачах в гите и трекерах. Это действия кажутся незначительными, но именно они ведут к великой цели.
Больше всего этой тематикой интересовались тимлиды, руководящие небольшой командой от 5 до 10 человек, в более крупной компании (до 50 человек). Они пробовали что-то документировать, вести вики, но их никто не поддержал. А больше всего их беспокоит невозможность быстро вводить новых сотрудников в курс дела и bus-factor при распределении задач. Если же говорить о платформах, чаще всего люди работают с Gitlab, Google Docs и Jira+Confluence (даже те, кто используют Atlassian стек зачастую предпочитают GitLab 😄 ).
Одним из самых занятных вопросов, который мне задали был: "У нас есть продукт с огромным количеством легаси, разрабатывающийся уже более 5 лет. Никто не знает, почему в продукте сделано то или иное, а что гораздо важее - почему что-то не сделано. Как нам это узнать?". Этот вопрос прекрасен тем, что он противоречит сам себе и здравому смыслу: ничто не поможет вам вспомнить то, чего вы не знаете.
Тем, кто попал в подобную ситуацию можно пожелать сфокусироваться не на упущенном прошлом, но на будущем: что сделать сейчас, чтобы ещё через 5 лет вы так же не страдали о решениях, которые делаются сейчас. Какие организационные решения принять сейчас, чтобы через N месяцев не было bus factor-а при распределении задач, как наиболее простым способом попросить разработчиков оставить чуть больше информации о задачах в гите и трекерах. Это действия кажутся незначительными, но именно они ведут к великой цели.
Тут идёт голосование для вручения премии Highload++ 2019.
Предполагается, что премией должны быть награждены люди, которые оказали значительное позитивное влияние на отрасль в целом, продвинули её вперёд к добру, свету и позитиву. Голосование вот тут: http://www.highload.ru/moscow/2019/award (красная кнопка "Проголосовать" справа)
И не то, чтобы я призывал голосовать за какого-то кандидата, но именно это я сейчас и попробую сделать 🙂
Мне кажется, человек, который очень достоин премии, но может быть позабыт - это Филлип Кулин, автор https://usher2.club/ и неугомонный борец с безумием в органах власти. Роскомнадзор и попытки управлять интернетом никуда не денутся, некомпетентность управленцев - останется, и мне кажется, что без работы таких людей как Фил (а он не только делает сервисы, публично вскрывает абсурд и косяки в работе гос. органов, но и пытается общаться с госами на их языке, чтобы ну хоть как-то повлиять на ситуацию), в нашей действительности - никак.
Фил достоин, голосуйте, пожалуйста, за Фила.
Предполагается, что премией должны быть награждены люди, которые оказали значительное позитивное влияние на отрасль в целом, продвинули её вперёд к добру, свету и позитиву. Голосование вот тут: http://www.highload.ru/moscow/2019/award (красная кнопка "Проголосовать" справа)
И не то, чтобы я призывал голосовать за какого-то кандидата, но именно это я сейчас и попробую сделать 🙂
Мне кажется, человек, который очень достоин премии, но может быть позабыт - это Филлип Кулин, автор https://usher2.club/ и неугомонный борец с безумием в органах власти. Роскомнадзор и попытки управлять интернетом никуда не денутся, некомпетентность управленцев - останется, и мне кажется, что без работы таких людей как Фил (а он не только делает сервисы, публично вскрывает абсурд и косяки в работе гос. органов, но и пытается общаться с госами на их языке, чтобы ну хоть как-то повлиять на ситуацию), в нашей действительности - никак.
Фил достоин, голосуйте, пожалуйста, за Фила.
Уютный IT адочек
московских митапов пост Чуть больше чем через неделю в гостях у SkyEng хочу поговорить об управлении знаниями. Про то, как начать, если вы уже что-то попробовали, но ничего не получилось. Про то, что делать, если у вас Confluence, GitLab, Slack и/или ещё…
Митапа в SkyEng пост
На митапе была достаточно неожиданная для меня аудитория. Весьма разношёрстная, но больше всего было разработчиков и тимлидов.
Мы приятно побеседовали о шаринге знаний, адаптации, тайнах, скрытых в легаси и документации. Однако, некоторые озвучившиеся тезисы практически лишают меня дара речи:
- Не надо париться по поводу шаринга знаний - надо просто заставить всех писать комментарии в Жире
- Управление знаниями - это дока
- Люди не хотят писать, потому что это технически сложно
- Нет ничего проще, чем заставить людей шарить знания, у них же есть начальник? Вот он пусть даст указание.
Мне кажется, что проблема всех этих утверждений, что они не про то, как люди договариваются об общей выгоде. И, как следствие этого, не видят тысячи нюансов и пограничных состояний, которые нельзя увидеть только из одной головы.
На самом деле при наличии хорошего лидера в команде, нет ничего проще, чем заставить разработчиков вести папочку с документацией в проекте. И чисто теоретически этот опыт можно даже масштабировать и использовать для внедрения в уже существующей компании. Но является ли это решением исходной проблемы шаринга знаний?
На самом деле, не совсем: наличие доки не говорит о том, что дока понятна, полна и актуальна. Кроме того, есть гипотеза, что документирование, внедрённое подобной жёсткой рукой, уводит людей от фокуса на эффективных, out of the box решениях. И, самое главное, если для компании стоит вопрос о том, чтобы выжить - не факт, что дока является для неё ключевым вопросом (хотя есть бизнесы, для которых - факт, но глупо апроксимировать бездумно).
Примерно три года назад я говорил, что дока - всему голова, что нужно работать по принципу "сперва документация", но, к счастью, жизнь гораздо богаче.
И пусть это многообразие не останавливает вас от того, чтобы пробовать новое, будь ваша рука жёсткой как камень, или любящей, как поцелуй близкого человека. Прошу об одном: смотрите вокруг, ищите границы своего знания и стремитесь выйти за них.
На митапе была достаточно неожиданная для меня аудитория. Весьма разношёрстная, но больше всего было разработчиков и тимлидов.
Мы приятно побеседовали о шаринге знаний, адаптации, тайнах, скрытых в легаси и документации. Однако, некоторые озвучившиеся тезисы практически лишают меня дара речи:
- Не надо париться по поводу шаринга знаний - надо просто заставить всех писать комментарии в Жире
- Управление знаниями - это дока
- Люди не хотят писать, потому что это технически сложно
- Нет ничего проще, чем заставить людей шарить знания, у них же есть начальник? Вот он пусть даст указание.
Мне кажется, что проблема всех этих утверждений, что они не про то, как люди договариваются об общей выгоде. И, как следствие этого, не видят тысячи нюансов и пограничных состояний, которые нельзя увидеть только из одной головы.
На самом деле при наличии хорошего лидера в команде, нет ничего проще, чем заставить разработчиков вести папочку с документацией в проекте. И чисто теоретически этот опыт можно даже масштабировать и использовать для внедрения в уже существующей компании. Но является ли это решением исходной проблемы шаринга знаний?
На самом деле, не совсем: наличие доки не говорит о том, что дока понятна, полна и актуальна. Кроме того, есть гипотеза, что документирование, внедрённое подобной жёсткой рукой, уводит людей от фокуса на эффективных, out of the box решениях. И, самое главное, если для компании стоит вопрос о том, чтобы выжить - не факт, что дока является для неё ключевым вопросом (хотя есть бизнесы, для которых - факт, но глупо апроксимировать бездумно).
Примерно три года назад я говорил, что дока - всему голова, что нужно работать по принципу "сперва документация", но, к счастью, жизнь гораздо богаче.
И пусть это многообразие не останавливает вас от того, чтобы пробовать новое, будь ваша рука жёсткой как камень, или любящей, как поцелуй близкого человека. Прошу об одном: смотрите вокруг, ищите границы своего знания и стремитесь выйти за них.
Пятницы пост 🙂
Перевели тут вдохновившую меня статью про оформление коммитов в Git:
https://habr.com/ru/company/flant/blog/472278/
Перевели тут вдохновившую меня статью про оформление коммитов в Git:
https://habr.com/ru/company/flant/blog/472278/
Хабр
Мой любимый Git-коммит
Прим. перев.: Эта публикация британского программиста, ставшая настоящим хитом в англоязычном интернете, ссылается на Git-коммит 6-летней давности. Он был зафикс...
Определения термина "легаси" пост
На хайлоаде организовали большой митап на тему легаси. И, хотя термин кажется очевидным, всё-таки от определения зависят акценты и взгляд на проблему.
Самым популярным невысказанным было: "легаси - это когда жуткий монолит". Оооочень спорное утверждение, на мой взгляд, как бы подразумевающий, что всё надо переписать на микросервисы. Однако, практический опыт (https://www.youtube.com/watch?v=g9cgppj0gKQ) говорит, что микросервисы легко превращаются в сильносвязанную кучу грязи, чудовищно сложную в доработке. Страдающим от монолита скорее стоит учиться кодить монолит.
А ещё было: "легаси - это то, у которого бас-фактор маленький". Прекрасное определение, но беда в том, чтобы этот самый бас-фактор померить. Практика подсказывает: легаси на то и легаси, что фиг разберёшься что в проекте, зачем и как реализовано. Нельзя измерить то, не знаю что.
Измерять тем, что известно о требованиях? Может быть документацией? Тоже такая себе идея, достаточно вполне живых, "не-легаси" проектов без доки и очень много зависит от размеров.
Однако, похоже наверняка можно сказать, что проект становится легаси, если обрывается нить передачи знаний от поколения к поколению, например, при передаче проекта исполнителем в случае заказной разработки. И, что характерно, это не всегда становится проблемой.
Самое же прекрасное определение, которое было дано, меня бесконечно вдохновило:
У каждого разрабатываемого проекта есть запас гибкости. Легаси - это проект, в котором запас гибкости исчерпан.
Определение это прекрасно тем, что даёт нам совершенно иной взгляд на проблему: легаси - это вопрос способности адаптироваться. Это гораздо проще измерить (даже эмпирически), для повышения способности адаптироваться есть вполне конкретные приёмы и методики, и оно вполне себе понятно на бизнес-уровне и может служить основой для переговоров бизнеса с разработкой.
Подумайте в таком ключе и поделитесь своими мыслями со страдающими от легаси коллегами, глядишь - и всем станет жить легче.
На хайлоаде организовали большой митап на тему легаси. И, хотя термин кажется очевидным, всё-таки от определения зависят акценты и взгляд на проблему.
Самым популярным невысказанным было: "легаси - это когда жуткий монолит". Оооочень спорное утверждение, на мой взгляд, как бы подразумевающий, что всё надо переписать на микросервисы. Однако, практический опыт (https://www.youtube.com/watch?v=g9cgppj0gKQ) говорит, что микросервисы легко превращаются в сильносвязанную кучу грязи, чудовищно сложную в доработке. Страдающим от монолита скорее стоит учиться кодить монолит.
А ещё было: "легаси - это то, у которого бас-фактор маленький". Прекрасное определение, но беда в том, чтобы этот самый бас-фактор померить. Практика подсказывает: легаси на то и легаси, что фиг разберёшься что в проекте, зачем и как реализовано. Нельзя измерить то, не знаю что.
Измерять тем, что известно о требованиях? Может быть документацией? Тоже такая себе идея, достаточно вполне живых, "не-легаси" проектов без доки и очень много зависит от размеров.
Однако, похоже наверняка можно сказать, что проект становится легаси, если обрывается нить передачи знаний от поколения к поколению, например, при передаче проекта исполнителем в случае заказной разработки. И, что характерно, это не всегда становится проблемой.
Самое же прекрасное определение, которое было дано, меня бесконечно вдохновило:
У каждого разрабатываемого проекта есть запас гибкости. Легаси - это проект, в котором запас гибкости исчерпан.
Определение это прекрасно тем, что даёт нам совершенно иной взгляд на проблему: легаси - это вопрос способности адаптироваться. Это гораздо проще измерить (даже эмпирически), для повышения способности адаптироваться есть вполне конкретные приёмы и методики, и оно вполне себе понятно на бизнес-уровне и может служить основой для переговоров бизнеса с разработкой.
Подумайте в таком ключе и поделитесь своими мыслями со страдающими от легаси коллегами, глядишь - и всем станет жить легче.
Легаси-боли пост
А что болит-то, когда мы сталкиваемся с легаси?
Болит то, что когда ты вносишь правки - неизвестно где отвалится. К слову, мне неизвестно, существуют ли легаси-проекты с хорошим покрытием автотестами. Интуитивно это не очень очевидно.
Болит, что в проекте обычно есть какие-то специальные "галочки", сделанные неизвестно для кого и для чего. А иногда - сделанные ради удовлетворения какого-то одного человека со странными, непонятными запросами. И хочется эти "галочки" со связанной с ними логикой выпилить, но представитель заказачика исчез с радаров, и никто не может решить что делать с его требованиями. А бывает ещё хуже: особый представитель заказчика никуда не делся, но ушёл на повышение и, хотя формально присутствует, фактически к нему уже не пробиться.
Болит то, что порезаны бюджеты и рефакторинг, всё-таки присутствующий во время разработки, начисто прирезан.
Ну и, конечно, у разработчиков болят устаревшие технологии, с которыми не хочется возиться и в которых есть "тупые проблемы" и "много лишнего кода". Это моя любимая боль, потому что бизнес на такое морщит нос и говорит "так я вам за это и плачу деньги", что порождает ещё больше проблем, но никак не решений.
И, разумеется, проблемой становится отладка. Какие куски приложения с чем связаны, куда ходят - и в современных кластерах на Kubernetes выявить зависимости является нетривиальной задачей, а уж на устаревшем стеке технологий - и подавно.
Однако, мне всё-таки кажется, что зачастую страдающие от "невозможной отладки" просто недостаточно компетентны в инструментах отладки.
Возможно это хорошая ниша для создания обучающих курсов / докладов / статей: "инструменты отладки для адового легаси".
Ну и, конечно, болят философские вопросы в стиле:
- За что мне это?
- Когда всё это кончится?
- Если руководитель скинул на меня этот проект - он меня хочет уволить или наоборот считает, что я крутой?
Если у вас отзывается что-то из написанного выше - мужайтесь и знайте: вы не одиноки. Возможно у вас получится изменить ситуацию или своё отношение к ней. Главное - оставайтесь крутым профессионалом и хорошим человеком.
А что болит-то, когда мы сталкиваемся с легаси?
Болит то, что когда ты вносишь правки - неизвестно где отвалится. К слову, мне неизвестно, существуют ли легаси-проекты с хорошим покрытием автотестами. Интуитивно это не очень очевидно.
Болит, что в проекте обычно есть какие-то специальные "галочки", сделанные неизвестно для кого и для чего. А иногда - сделанные ради удовлетворения какого-то одного человека со странными, непонятными запросами. И хочется эти "галочки" со связанной с ними логикой выпилить, но представитель заказачика исчез с радаров, и никто не может решить что делать с его требованиями. А бывает ещё хуже: особый представитель заказчика никуда не делся, но ушёл на повышение и, хотя формально присутствует, фактически к нему уже не пробиться.
Болит то, что порезаны бюджеты и рефакторинг, всё-таки присутствующий во время разработки, начисто прирезан.
Ну и, конечно, у разработчиков болят устаревшие технологии, с которыми не хочется возиться и в которых есть "тупые проблемы" и "много лишнего кода". Это моя любимая боль, потому что бизнес на такое морщит нос и говорит "так я вам за это и плачу деньги", что порождает ещё больше проблем, но никак не решений.
И, разумеется, проблемой становится отладка. Какие куски приложения с чем связаны, куда ходят - и в современных кластерах на Kubernetes выявить зависимости является нетривиальной задачей, а уж на устаревшем стеке технологий - и подавно.
Однако, мне всё-таки кажется, что зачастую страдающие от "невозможной отладки" просто недостаточно компетентны в инструментах отладки.
Возможно это хорошая ниша для создания обучающих курсов / докладов / статей: "инструменты отладки для адового легаси".
Ну и, конечно, болят философские вопросы в стиле:
- За что мне это?
- Когда всё это кончится?
- Если руководитель скинул на меня этот проект - он меня хочет уволить или наоборот считает, что я крутой?
Если у вас отзывается что-то из написанного выше - мужайтесь и знайте: вы не одиноки. Возможно у вас получится изменить ситуацию или своё отношение к ней. Главное - оставайтесь крутым профессионалом и хорошим человеком.
хранения паролей пост
Свои более чем 500 паролей я храню в KeePass. Он имеет множество реализаций на все платформы (удивительно, но MacPass оказался лучше всего, плюс умеет мерджить два файла) и в общем-то закрывает стандартный набор проблем (шифрование хранилища, напоминания о необходимости сменить пароли, широкие возможности по сортировке и управлению).
Но у меня не один ноутбук. И изменения в список паролей не всегда вносятся при наличии интернета. А значит хранить контейнер с паролями, например, на Google Drive - не вариант: высок риск получить конфликт изменений и в итоге что-то продолбать.
Варианты были разные, в итоге я сформулировал мини-тз (https://news.1rj.ru/str/pet_project_ideas/9) на специальную железку, которая бы решила проблему. Очень хотелось одновременную работу с несколькими устройствами и кросплатформенность. Я перебрал кучу решений, пытался состыковать и так и так по-быстрому, чтобы не тратить месяц на написание низкоуровнего кода - без толку. Готовых кубиков нет.
А потом я наткнулся на https://www.sparkleshare.org/ и подумал: а зачем я так усложняю? Ведь для меня главное - это не продолбать ни одно изменение, а вовсе не "одновременная работа". Git для этого идеален! Штука простая как топор, вроде как даже не сложно пишется самостоятельно.
В общем, рекомендую попробовать. Учтите только, что SparkleShare не умеет использовать ssh-ключи из системы и генерирует свой, который надо вытащить и закинуть в свой гит.
Свои более чем 500 паролей я храню в KeePass. Он имеет множество реализаций на все платформы (удивительно, но MacPass оказался лучше всего, плюс умеет мерджить два файла) и в общем-то закрывает стандартный набор проблем (шифрование хранилища, напоминания о необходимости сменить пароли, широкие возможности по сортировке и управлению).
Но у меня не один ноутбук. И изменения в список паролей не всегда вносятся при наличии интернета. А значит хранить контейнер с паролями, например, на Google Drive - не вариант: высок риск получить конфликт изменений и в итоге что-то продолбать.
Варианты были разные, в итоге я сформулировал мини-тз (https://news.1rj.ru/str/pet_project_ideas/9) на специальную железку, которая бы решила проблему. Очень хотелось одновременную работу с несколькими устройствами и кросплатформенность. Я перебрал кучу решений, пытался состыковать и так и так по-быстрому, чтобы не тратить месяц на написание низкоуровнего кода - без толку. Готовых кубиков нет.
А потом я наткнулся на https://www.sparkleshare.org/ и подумал: а зачем я так усложняю? Ведь для меня главное - это не продолбать ни одно изменение, а вовсе не "одновременная работа". Git для этого идеален! Штука простая как топор, вроде как даже не сложно пишется самостоятельно.
В общем, рекомендую попробовать. Учтите только, что SparkleShare не умеет использовать ssh-ключи из системы и генерирует свой, который надо вытащить и закинуть в свой гит.
Переговоров с руководством про легаси пост
Когда легаси входит в жизнь разработчиков - они, как правило, начинают сопротивляться. По тысяче причин. И в какой-то момент, конечно, приходят к руководству с предложением переписать то или иное.
Ответ, как правило, шаблонный:
Это офигенный ответ по нескольким причинам:
- Он вроде правильный
- Он выглядит простым
- Самостоятельно разработчик просто не способен этого сделать. Как и его руководитель, не знающий техническую матчасть.
- Скорее всего, никто не способен этого сделать: такой расчёт - он скорее про статистику и гадание на кофейной гуще, чем про математику.
И ещё - сюрприз! - беда может быть в чём-то фундаментальном. И приходят не за тем, чтобы бизнес с барского плеча разрешил "пару часов в неделю потратить", а за чем-то серьёзным. Либо за неделей-другой, либо за серьёзной инвестицией хороших out of the box мозгов, которых разработчику не хватает.
Бизнес легко задавливает позицию разработчиков с своей доминирующей позиции. А разработчики голосуют ногами, увольняясь, либо применяют совсем коварное враньё и манипуляции. И то и другое - деструктивные шаблоны.
Чуть менее деструктивны "программисты со сломанным духом", которые остаются в легаси жить навсегда, руководствуясь тем, что их и тут неплохо кормят. Не осуждаю, но сочувствую.
Мне кажется, что есть только один путь победы над легаси - это путь самурая. Делай то, что должно и будь, что будет. Учись на ошибках, верь в себя и коллег на всех уровнях.
Не конструктивно играть в жертву обстоятельств в ключе "я просто получаю от этого проекта деньги" или "моё дело маленькое - закрывать тикеты". Это ваша жизнь, и она всегда содержит и некоторую долю легаси, и некоторое пространство для манёвра. И у вас всегда есть возможность задавать конструктивные и прямые вопросы о проблемах.
Когда легаси входит в жизнь разработчиков - они, как правило, начинают сопротивляться. По тысяче причин. И в какой-то момент, конечно, приходят к руководству с предложением переписать то или иное.
Ответ, как правило, шаблонный:
давай посчитаем окупаемость твоих правок. Мол, сколько денег уйдёт на переписывание, и какой профит мы от этого получим.Это офигенный ответ по нескольким причинам:
- Он вроде правильный
- Он выглядит простым
- Самостоятельно разработчик просто не способен этого сделать. Как и его руководитель, не знающий техническую матчасть.
- Скорее всего, никто не способен этого сделать: такой расчёт - он скорее про статистику и гадание на кофейной гуще, чем про математику.
И ещё - сюрприз! - беда может быть в чём-то фундаментальном. И приходят не за тем, чтобы бизнес с барского плеча разрешил "пару часов в неделю потратить", а за чем-то серьёзным. Либо за неделей-другой, либо за серьёзной инвестицией хороших out of the box мозгов, которых разработчику не хватает.
Бизнес легко задавливает позицию разработчиков с своей доминирующей позиции. А разработчики голосуют ногами, увольняясь, либо применяют совсем коварное враньё и манипуляции. И то и другое - деструктивные шаблоны.
Чуть менее деструктивны "программисты со сломанным духом", которые остаются в легаси жить навсегда, руководствуясь тем, что их и тут неплохо кормят. Не осуждаю, но сочувствую.
Мне кажется, что есть только один путь победы над легаси - это путь самурая. Делай то, что должно и будь, что будет. Учись на ошибках, верь в себя и коллег на всех уровнях.
Не конструктивно играть в жертву обстоятельств в ключе "я просто получаю от этого проекта деньги" или "моё дело маленькое - закрывать тикеты". Это ваша жизнь, и она всегда содержит и некоторую долю легаси, и некоторое пространство для манёвра. И у вас всегда есть возможность задавать конструктивные и прямые вопросы о проблемах.
Принятия решения о задачах пост
В ответ на предыдущий пост @MargaritaAndrianova прислала мне описание подхода к ранжированию задач, который в некоторых ситуациях может помочь разгрести хвосты по техдолгу:
https://docs.google.com/presentation/d/1-DIhhQj4RaeMGfTCF0AhegHt2x6lIvVQr083RQRgHXM/edit
И хотя он не отвечает на вопросы "как договориться с бизнесом, что пора всерьез начать разгребать легаси?" или "за что мне это?" - не могу не поделиться этой заготовкой. Возможно она наведет вас на мысли о своем подходе.
В ответ на предыдущий пост @MargaritaAndrianova прислала мне описание подхода к ранжированию задач, который в некоторых ситуациях может помочь разгрести хвосты по техдолгу:
https://docs.google.com/presentation/d/1-DIhhQj4RaeMGfTCF0AhegHt2x6lIvVQr083RQRgHXM/edit
И хотя он не отвечает на вопросы "как договориться с бизнесом, что пора всерьез начать разгребать легаси?" или "за что мне это?" - не могу не поделиться этой заготовкой. Возможно она наведет вас на мысли о своем подходе.
Google Docs
Ранжирование
Ранжирование задач Алгоритм определения порядка выполнения задач в сложных ситуациях
Расчётов пост
В одном из выпусков прекрасного комикса XKCD (https://xkcd.com/1205/, если быть точным) была чудесная таблица: сколько времени нужно, чтобы окупилась автоматизация.
Но она расчитана исходя из образа жизни автора (рабочие дни в году, рабочие часы, вот это всё).
Я сделал параметризованную версию этой таблицы для вас:
https://docs.google.com/spreadsheets/d/1YM0F7Fsviy5JWPqtfdZwCsyGYFJLT2umBsZ1SBu0ALM/edit?usp=sharing
В одном из выпусков прекрасного комикса XKCD (https://xkcd.com/1205/, если быть точным) была чудесная таблица: сколько времени нужно, чтобы окупилась автоматизация.
Но она расчитана исходя из образа жизни автора (рабочие дни в году, рабочие часы, вот это всё).
Я сделал параметризованную версию этой таблицы для вас:
https://docs.google.com/spreadsheets/d/1YM0F7Fsviy5JWPqtfdZwCsyGYFJLT2umBsZ1SBu0ALM/edit?usp=sharing
xkcd
Is It Worth the Time?
Онбординга пост
В субботу днём буду на DevOpsDays, общаться про технологический онбординг.
Кроме организационного онбординга (посадить на рабочее место, дать технику, познакомить с нужными людьми, придать ускорение в нужном направлении) есть ещё технологическая составляющая. Потому что, как ни крути, у всех есть своё легаси, свои особенные практики, свои соглашения о том как писать код, описывать задачи и участвовать в движухе типа планирования. И HR-ы, которые зачастую занимаются онбордингом, ничего в этом не понимают и по сути ответить на вопросы не могут.
А ещё веселее становится, когда все эти практики-технологии быстро эволюционируют и, например, физически невозможно нанять человека знающего весь необходимый набор технологий и инструментов. Надо людей прокачивать как можно быстрее, но как?
Окей, в теории всё просто: чек-листы, наставничество, парное программирование, ревью, записанные видео и статьи - но что из этого действительно работает на практике и почему? А что - не работает?
Я, например, пробовал организовывать в командах учебные задачи для новичков в рамках "курса молодого бойца". Идея казалась прекрасной: снять нагрузку с тимлида, чтобы инженер в "учебных", "лайтовых" условиях мог освоить базовые вещи и затем идти в одну из команд и доучиваться "в бою".
Но на практике:
а) снятие нагрузки с тимлидов оказалось порочной затеей, так как они полностью отстранились и стали рассчитывать на чудо, не желая даже участвовать в детализации курса;
б) базовые, фундаментальные вещи и приёмы в разных командах оказались разными. И команды отстранялись от попыток их синхронизировать.
в) оказалось, что курса молодого бойца даже в одну неделю не хватает на ощутимый результат: объём информации и знаний слишком большой. А тащить человека дольше без погружения в реальную практику выглядело полным бредом.
🤔 возможно, вы знаете как обойти эти проблемы. У меня, в свою очередь, есть другие истории, которые взлетели и дали отдачу, не смотря на встреченные подводные камни.
Не хочется превращать пост в простыню. Лучше поделимся своей болью интерактивно на митапе в субботу или в канале @KnowledgeConfChannel.
В субботу днём буду на DevOpsDays, общаться про технологический онбординг.
Кроме организационного онбординга (посадить на рабочее место, дать технику, познакомить с нужными людьми, придать ускорение в нужном направлении) есть ещё технологическая составляющая. Потому что, как ни крути, у всех есть своё легаси, свои особенные практики, свои соглашения о том как писать код, описывать задачи и участвовать в движухе типа планирования. И HR-ы, которые зачастую занимаются онбордингом, ничего в этом не понимают и по сути ответить на вопросы не могут.
А ещё веселее становится, когда все эти практики-технологии быстро эволюционируют и, например, физически невозможно нанять человека знающего весь необходимый набор технологий и инструментов. Надо людей прокачивать как можно быстрее, но как?
Окей, в теории всё просто: чек-листы, наставничество, парное программирование, ревью, записанные видео и статьи - но что из этого действительно работает на практике и почему? А что - не работает?
Я, например, пробовал организовывать в командах учебные задачи для новичков в рамках "курса молодого бойца". Идея казалась прекрасной: снять нагрузку с тимлида, чтобы инженер в "учебных", "лайтовых" условиях мог освоить базовые вещи и затем идти в одну из команд и доучиваться "в бою".
Но на практике:
а) снятие нагрузки с тимлидов оказалось порочной затеей, так как они полностью отстранились и стали рассчитывать на чудо, не желая даже участвовать в детализации курса;
б) базовые, фундаментальные вещи и приёмы в разных командах оказались разными. И команды отстранялись от попыток их синхронизировать.
в) оказалось, что курса молодого бойца даже в одну неделю не хватает на ощутимый результат: объём информации и знаний слишком большой. А тащить человека дольше без погружения в реальную практику выглядело полным бредом.
🤔 возможно, вы знаете как обойти эти проблемы. У меня, в свою очередь, есть другие истории, которые взлетели и дали отдачу, не смотря на встреченные подводные камни.
Не хочется превращать пост в простыню. Лучше поделимся своей болью интерактивно на митапе в субботу или в канале @KnowledgeConfChannel.
JetBrains Space
Мне пришёл доступ в Space. Если вы ещё не слышали про него - посмотрите https://www.jetbrains.com/space/ - там весьма неплохо описан концепт. Далее - мои субъективные впечатления.
В главном меню есть пункты: единый поиск (открывающийся по хоткею, не умеет в русскую морфологию и уж тем более семантику), чаты и плюс-минус "стандартный" набор для управления проектами: гит репы, issues, работа над merge request-ами и отдельно вынесенные Checklists проекта.
Мне пришёл доступ в Space. Если вы ещё не слышали про него - посмотрите https://www.jetbrains.com/space/ - там весьма неплохо описан концепт. Далее - мои субъективные впечатления.
В главном меню есть пункты: единый поиск (открывающийся по хоткею, не умеет в русскую морфологию и уж тем более семантику), чаты и плюс-минус "стандартный" набор для управления проектами: гит репы, issues, работа над merge request-ами и отдельно вынесенные Checklists проекта.
Отдельно выделено внимание для блогов. Платформа прямо призывает тебя сразу начать писать статьи.
Это реально интересная идея, чтобы хакнуть людей и сподвигнуть их написать что-нибудь.
Конечно, это не отменяет необходимости в обучении людей писать правильно и использовать этот инструмент, но, честно говоря, это самое вменяемое, что я видел.
Это реально интересная идея, чтобы хакнуть людей и сподвигнуть их написать что-нибудь.
Конечно, это не отменяет необходимости в обучении людей писать правильно и использовать этот инструмент, но, честно говоря, это самое вменяемое, что я видел.
Отдельного внимания заслуживают чаты.
"Зачем делать чаты в 2019-ом году?" - задавался я вопросом, когда читал описание Space.
А вот зачем: на статьи автоматом создаются чаты, на мердж реквесты создаются чаты, и вообще выглядит, как будто коммуникации грамотно разруливаются на те предметы, которые появляются в базе знаний.
Отдельно доставило автоматически созданный чат "Absense" - для оповещения людей об отсутствии. У нас есть нечто подобное, но мы работаем с отсутствиями вручную. Для распределённой команды, например, такой чат весьма необходим, здорово, что такие мелочи сразу идут продуманными из коробки.
"Зачем делать чаты в 2019-ом году?" - задавался я вопросом, когда читал описание Space.
А вот зачем: на статьи автоматом создаются чаты, на мердж реквесты создаются чаты, и вообще выглядит, как будто коммуникации грамотно разруливаются на те предметы, которые появляются в базе знаний.
Отдельно доставило автоматически созданный чат "Absense" - для оповещения людей об отсутствии. У нас есть нечто подобное, но мы работаем с отсутствиями вручную. Для распределённой команды, например, такой чат весьма необходим, здорово, что такие мелочи сразу идут продуманными из коробки.
Конечно, я совсем не коснулся вопросов работы с кодом, сборки и доставки. Потыкаюсь ближе к выходным, но поверхностно выглядит функционально.
Уютный IT адочек
Онбординга пост В субботу днём буду на DevOpsDays, общаться про технологический онбординг. Кроме организационного онбординга (посадить на рабочее место, дать технику, познакомить с нужными людьми, придать ускорение в нужном направлении) есть ещё технологическая…
Технологический онбординг - это погружение в проекты, технологии и специфические соглашения, которые приняты в команде: как писать код, почему используется PostgreSQL вместо MySQL, какие сервисы используются в проекте и как они связаны между собой и другое.
Есть компании, в которых делают полноценный курс новичка: наборы видеозаписей, отвечающих на самые частые вопросы, статьи, обучалки - но как бы то ни было, поддерживать подобный курс очень дорого и тяжело.
Все задают вопрос "как принять решение - стоит какую-то информацию фиксировать в виде доки или нет?" - но внятного ответа мне пока неизвестно. И есть впечатление, что хорошего ответа ни у кого нет.
Есть и ключевая проблема с подобным "курсом новичка" - большой объём материала невозможно запихнуть в голову мгновенно. Всего лишь какие-то 6 часов видео убьют любой мозг, как ни крути.
Таким образом, онбординг следует по смыслу разделять на две части:
- минимальную информацию, которую нужно донести за 2..3 дня максимум.
- общие меры, направленные на улучшение обмена знаниями в команде, которые будут помогать онбордящемуся в первые 2..3 месяца.
Минимальная информация - это строго то, что вызывает реальную боль у новичков. Выявить её очень просто - вести их в течение первой недели-полутора, присутствовать на всех ключевых встречах с человеком, работать в режиме парного программирования и проверять его прогресс.
Общие меры - это, прежде всего, наставничество и создание правильной культуры, подразумевающей качественный фидбэк, свободу в задавании вопросов и другое - но это сами по себе обширные темы, которые надо рассматривать отдельно.
Есть компании, в которых делают полноценный курс новичка: наборы видеозаписей, отвечающих на самые частые вопросы, статьи, обучалки - но как бы то ни было, поддерживать подобный курс очень дорого и тяжело.
Все задают вопрос "как принять решение - стоит какую-то информацию фиксировать в виде доки или нет?" - но внятного ответа мне пока неизвестно. И есть впечатление, что хорошего ответа ни у кого нет.
Есть и ключевая проблема с подобным "курсом новичка" - большой объём материала невозможно запихнуть в голову мгновенно. Всего лишь какие-то 6 часов видео убьют любой мозг, как ни крути.
Таким образом, онбординг следует по смыслу разделять на две части:
- минимальную информацию, которую нужно донести за 2..3 дня максимум.
- общие меры, направленные на улучшение обмена знаниями в команде, которые будут помогать онбордящемуся в первые 2..3 месяца.
Минимальная информация - это строго то, что вызывает реальную боль у новичков. Выявить её очень просто - вести их в течение первой недели-полутора, присутствовать на всех ключевых встречах с человеком, работать в режиме парного программирования и проверять его прогресс.
Общие меры - это, прежде всего, наставничество и создание правильной культуры, подразумевающей качественный фидбэк, свободу в задавании вопросов и другое - но это сами по себе обширные темы, которые надо рассматривать отдельно.