А нет, вот добивка. https://habr.com/ru/articles/777244/. На вид статья не сильно сложная, просто технические детали проектирования системы.
Но вчера на итоговом занятии группы, закончившей обучение на моем курсе мне ребята сказали, что им не хватило особенностей и тонкостей архитектурной проработки. А теперь, почитав эту статью, давайте попробуем подумать, где же должна пролегать граница работы системного аналитика и системного архитектора, который по сути схему из статьи и делает? Может СА писать про Cron? Наверное, может, но вот насколько это нужно насколько он может обосновать свой выбор?
Продумывать работу с кешом? Заниматься выбором оптимальной БД под задачу (вот я бы тут вообще отказался от реляционки в пользу условного редиса и сбрасывал его на диск раз в какой то период времени). Но могу ли я обосновать этот выбор? Пожалуй, что да, но мне тут в помощь 15 лет опыта, широкий кругозор и природная харизма😁.
Давайте подискутируем в комментариях!
Но вчера на итоговом занятии группы, закончившей обучение на моем курсе мне ребята сказали, что им не хватило особенностей и тонкостей архитектурной проработки. А теперь, почитав эту статью, давайте попробуем подумать, где же должна пролегать граница работы системного аналитика и системного архитектора, который по сути схему из статьи и делает? Может СА писать про Cron? Наверное, может, но вот насколько это нужно насколько он может обосновать свой выбор?
Продумывать работу с кешом? Заниматься выбором оптимальной БД под задачу (вот я бы тут вообще отказался от реляционки в пользу условного редиса и сбрасывал его на диск раз в какой то период времени). Но могу ли я обосновать этот выбор? Пожалуй, что да, но мне тут в помощь 15 лет опыта, широкий кругозор и природная харизма😁.
Давайте подискутируем в комментариях!
Хабр
Нужно ли разработчикам проектирование?
Я работаю в сфере разработки заказного программного обеспечения. Когда мы говорим о проектировании программного обеспечения, как правило перед нами всплывает такая картинка: Такие схемы для нас...
👍1
Кстати, а вдруг есть кто то на Кипре, я утром в субботу буду в Пафосе, а потом в Лимасоле, есть время примерно до 12-13 часов. Если есть кто то, можем встретиться
Еще один камень кину в сторону классических проджектов. Сегодня смотрел запись интенсива по прдуктовому менеджменту и там был вопрос, а где границы работы продакта. Один из вариантов был "от идеи до продакшена", звучит вроде здраво, но ведущая возмутилась: "Это как то по проджектовому звучит, довести до продакшена и бросить".
И вот тут у меня действительно сложилась картинка, почему деятельность менеджеров проектов мне так претит:
1. Раньше я уже упоминал про ориентацию на сроки и бюджет, а не на ценность. Сколько раз у меня такое было, что нужно приложить немного больше усилий и сделать конфетку. Но проджет либо сразу отметал идею, либо фейлил переговоры по ней с заказчиком, а один раз даже просто сказал, что заказчик отказал, хотя даже не выходил с этим предложением. Очень часто для таких специалистов лень или страх становились блокерами в донесении реальной ценности.
2. Фанатичное следование плану и желание всех на этот план натянуть. Никогда не забуду, как чудесные проджекты из одной из компаний большой четверки перед сдачей устраивали ежечасные статусы накануне сдачи проекта, задолбав всю команду. В два часа ночи (дада, статусы продолжались) я просто сказал, что иду спать невзирая на их возмущения, моему примеру последовала вся команда.
3. Умение и желание спихивать с себя ответственность. Однажды был проект,в рамках которого требовалось загрузить в систему клиентскую базу в несколько сотен тысяч клиентов с договорами, актами и прочим атрибутивным составом. Система была оборудована встроенным 1с подобным интерпретатором (но это не 1С), были варианты грузить через него, делать все проверки бизнес логики, дедупликацию, сверку и тд, все в интерпретаторе в несколько потоков. Или грузить нативно из табличек в SQL и там скриптами проверять и все делать. Первый вариант выглядел дешевле - все проверки уже есть в бизнес логике системы, почему бы не переиспользовать. Я написал четко, почему это будет работать долго, плохо и больно, однако это же было дешевле в разработке и сдедали по первому варианту. В результате загрузка из 3 недель превратилась в 4-месячное полуручное адище с ручной разбивкой файлов и подбором оптимального размера файла. Надо ли говорить, что проджект пытался обвинить меня в недостатках проектирования и изучения данных, спасло меня только то, что все было зафиксировано в письме.
4. И это тот самый поинт из начала поста, им реально все равно, что будет после завершения проекта, продакшен - уже не их зона ответственности, сколько раз я это слышал - нам главное сдать, а там посмотрим, найдут - доделаем, или на проекте развития. Что это не решает проблем пользователей и заказчика в целом было все равно.
Я прекрасно понимаю, что далеко не все проджект менеджеры такие, но большая часть людей, работают на отвали и это печально.
И вот тут у меня действительно сложилась картинка, почему деятельность менеджеров проектов мне так претит:
1. Раньше я уже упоминал про ориентацию на сроки и бюджет, а не на ценность. Сколько раз у меня такое было, что нужно приложить немного больше усилий и сделать конфетку. Но проджет либо сразу отметал идею, либо фейлил переговоры по ней с заказчиком, а один раз даже просто сказал, что заказчик отказал, хотя даже не выходил с этим предложением. Очень часто для таких специалистов лень или страх становились блокерами в донесении реальной ценности.
2. Фанатичное следование плану и желание всех на этот план натянуть. Никогда не забуду, как чудесные проджекты из одной из компаний большой четверки перед сдачей устраивали ежечасные статусы накануне сдачи проекта, задолбав всю команду. В два часа ночи (дада, статусы продолжались) я просто сказал, что иду спать невзирая на их возмущения, моему примеру последовала вся команда.
3. Умение и желание спихивать с себя ответственность. Однажды был проект,в рамках которого требовалось загрузить в систему клиентскую базу в несколько сотен тысяч клиентов с договорами, актами и прочим атрибутивным составом. Система была оборудована встроенным 1с подобным интерпретатором (но это не 1С), были варианты грузить через него, делать все проверки бизнес логики, дедупликацию, сверку и тд, все в интерпретаторе в несколько потоков. Или грузить нативно из табличек в SQL и там скриптами проверять и все делать. Первый вариант выглядел дешевле - все проверки уже есть в бизнес логике системы, почему бы не переиспользовать. Я написал четко, почему это будет работать долго, плохо и больно, однако это же было дешевле в разработке и сдедали по первому варианту. В результате загрузка из 3 недель превратилась в 4-месячное полуручное адище с ручной разбивкой файлов и подбором оптимального размера файла. Надо ли говорить, что проджект пытался обвинить меня в недостатках проектирования и изучения данных, спасло меня только то, что все было зафиксировано в письме.
4. И это тот самый поинт из начала поста, им реально все равно, что будет после завершения проекта, продакшен - уже не их зона ответственности, сколько раз я это слышал - нам главное сдать, а там посмотрим, найдут - доделаем, или на проекте развития. Что это не решает проблем пользователей и заказчика в целом было все равно.
Я прекрасно понимаю, что далеко не все проджект менеджеры такие, но большая часть людей, работают на отвали и это печально.
👍6👎2
Очередной шедевр мысли от Дмитрия. В нем собраны основные мысли касательно изменения парадигмы управления компанией и ее элементами. Авторитарная модель становится менее эффективной и в посте приведено очень импонирующее мне обоснование. Задумайтесь и ответьте себя какое решение вы будете реализовать с большим желанием? Которое вам просто спустили? Или то, в выработке которого вы приняли самое деятельное участие? В целом это и есть принцип коллективной ответственности, когда вся команда договорилась, наша решение, которое устроит всех. Именно решение, которое устроит всех, а не компромисс. И вот тогда получается синергия, которая позволяет решить самые важные и сложные задачи относительно легко.
👍2👎1
Forwarded from Истории и Результаты (Дмитрий Филиппов)
Энергетическое обеспечение
Каждая компания которую я знаю, принимает гораздо, гораздо больше решений, чем выполняет. Я бы сказал, что в обычной компании из 100% принятых решений:
- 50% вообще никогда и никак не исполняются;
- 30% исполняются частично;
- 15% выполняется, но с задержками и компромиссами;
- и только 5% принятых решений выполняются точно и в срок.
Причина же подобного расхождения в том, что принятые решения не были обеспечены энергией. Именно отсутствие у исполнителей внутренних сил взяться за работу и довести ее до конца, а не дефицит времени, денег или других материальных активов является ключевой причиной того, что большая часть решений остается на бумаге.
Поэтому бизнесу очень выгодно научиться принимать решения командой, а не руководителями.
Решение спущенное сверху обеспечено только энергией руководства, и как только сместится фокус внимания менеджмента — интенсивность работы неминуемо начнет падать и довольно быстро сойдет на нет.
А решение принятое коллективно — обеспечено энергией всех принимавших. Подобные решения не просто дают кратно больший энергетический ресурс на входе, они еще и гораздо экономнее расходуют силы при реализации.
В этом кроется большой вызов для предпринимательства в современной русской трактовке. Наш предприниматель это прежде всего Я и мое Эго. Моя идея, мой бизнес, мои люди, мои активы и так далее. Ни в коем случае не говорю, что это плохо или хорошо — скорее необходимо для того чтобы этим самым предпринимателем стать.
Но для принятия решений командой потребуется позиция МЫ/НАШ. А это полностью противоположные предпринимательской душе движения: не собрать власть — а раздать власть, не получить актив в управление — а предать актив в управление. Делегировать полномочия принимать и отменять решения, закрепить право на ошибку и так далее.
Эти идеи не новы и лежат в основе таких интересных систем управления организациями как холакратия и социократия, которым будут посвящены ближайшие посты.
Каждая компания которую я знаю, принимает гораздо, гораздо больше решений, чем выполняет. Я бы сказал, что в обычной компании из 100% принятых решений:
- 50% вообще никогда и никак не исполняются;
- 30% исполняются частично;
- 15% выполняется, но с задержками и компромиссами;
- и только 5% принятых решений выполняются точно и в срок.
Причина же подобного расхождения в том, что принятые решения не были обеспечены энергией. Именно отсутствие у исполнителей внутренних сил взяться за работу и довести ее до конца, а не дефицит времени, денег или других материальных активов является ключевой причиной того, что большая часть решений остается на бумаге.
Поэтому бизнесу очень выгодно научиться принимать решения командой, а не руководителями.
Решение спущенное сверху обеспечено только энергией руководства, и как только сместится фокус внимания менеджмента — интенсивность работы неминуемо начнет падать и довольно быстро сойдет на нет.
А решение принятое коллективно — обеспечено энергией всех принимавших. Подобные решения не просто дают кратно больший энергетический ресурс на входе, они еще и гораздо экономнее расходуют силы при реализации.
В этом кроется большой вызов для предпринимательства в современной русской трактовке. Наш предприниматель это прежде всего Я и мое Эго. Моя идея, мой бизнес, мои люди, мои активы и так далее. Ни в коем случае не говорю, что это плохо или хорошо — скорее необходимо для того чтобы этим самым предпринимателем стать.
Но для принятия решений командой потребуется позиция МЫ/НАШ. А это полностью противоположные предпринимательской душе движения: не собрать власть — а раздать власть, не получить актив в управление — а предать актив в управление. Делегировать полномочия принимать и отменять решения, закрепить право на ошибку и так далее.
Эти идеи не новы и лежат в основе таких интересных систем управления организациями как холакратия и социократия, которым будут посвящены ближайшие посты.
👍2
Достаточно интересная статья про шаблонизацию ТЗ. https://habr.com/ru/companies/magnus-tech/articles/776732/
В ней очень грамотно отражен опыт заказной разработки, можно прямо брать и переиспользовать.
Я могу как обычно начать рассказывать, как это неэффективно и т.д. Но реальность такова, что все ещё много систем разрабатывается по модели аутсорса, когда ни заказчик ни исполнитель думают, не про пользу, а про соответствие единой точке правды в виде ТЗ. Для такой ситуации статья очень полезна, я в свое время работы в аутсорсе делал подобный шаблон, но не настолько подробно.
В ней очень грамотно отражен опыт заказной разработки, можно прямо брать и переиспользовать.
Я могу как обычно начать рассказывать, как это неэффективно и т.д. Но реальность такова, что все ещё много систем разрабатывается по модели аутсорса, когда ни заказчик ни исполнитель думают, не про пользу, а про соответствие единой точке правды в виде ТЗ. Для такой ситуации статья очень полезна, я в свое время работы в аутсорсе делал подобный шаблон, но не настолько подробно.
Хабр
Шаблонизируй это или Как ускорить разработку при помощи одного документа
Привет! На связи лид команды аналитиков Magnus Tech Владислава Никитина. В заказной разработке каждый проект начинается со сбора бизнес‑требований к будущей системе. Это важный...
👍4
Все привет! Заявок на менторинг поступило больще, чем три, что очень приятно! За выходные все отсмотрю и связусь с каждым написавшим и обсудим, почему я беру или не беру на менторинг конкретно его. Всем добра и хорошей пятницы!
👍5
Увидел сегодня гениальную игру от Юрия Куприянова (канал Системный сдвиг):
Придумал игру "Снежинки среди нас": новогодняя ИТ-мафия. Позволяет и развлечься, и прокачать софт-скиллы, и украсить офис к Новому году.
Правила как в Мафии, только роли такие:
— Скрам-мастер — ведущий. В игре не участвует, но следит за ритуалами.
— Заказчики. Их несколько, никто не знает, кто они, но каждую ночь они просыпаются и подбрасывают в бэклог новые таски, и могут, на выбор — либо забраковать произвольное число готовых задач ("не прошли приемку"), либо потребовать снять кого-нибудь с проекта. Таски выбираются из отдельной колоды с идеями по украшению офиса: вырезать снежинку, раскрасить гномика, сделать гирлянду и т.п. За одну ночь можно подкинуть в бэклог столько тасок, сколько осталось игроков. В начале игры бэклог наполняется тасками по числу игроков x2.
— Команда. Ночью спят, днём выполняют таски из бэклога. Заодно обсуждают, как вообще успеть сделать всё, что навалили, и кого можно выгнать, чтобы уже перестали наваливать. Тот, кого выгоняют, вскрывает свою карту и дальше участвует только как наблюдатель. Во время спринта ("днем") Заказчики работают, как члены команды.
— Продакт-оунер. Просыпается раньше всех, может либо проверить кого-то — не является ли тот Заказчиком, либо выкинуть из бэклога несколько задач, которые ещё не взяли в работу (до половины от числа оставшихся игроков).
— Ресурсный менеджер. Может спасти от снятия с проекта одного из членов Команды, но не дважды подряд. Себя может спасти только один раз.
— Человек-снежинка. Не является Заказчиком, но выигрывает, когда выигрывают они. Никакими специальными умениями не обладает, ночью не просыпается, но старается незаметно парализовать работу команды.
Игра заканчивается победой Команды, если всех Заказчиков выкинули (объявлен фича-фриз и можно спокойно доделать все задачи в работе).
Заказчики (и Снежинки) побеждают, когда Команда полностью разобрана (результат работы им достаётся бесплатно + неустойка).
Пока на практике играть не пробовал, но должно быть весело!
Придумал игру "Снежинки среди нас": новогодняя ИТ-мафия. Позволяет и развлечься, и прокачать софт-скиллы, и украсить офис к Новому году.
Правила как в Мафии, только роли такие:
— Скрам-мастер — ведущий. В игре не участвует, но следит за ритуалами.
— Заказчики. Их несколько, никто не знает, кто они, но каждую ночь они просыпаются и подбрасывают в бэклог новые таски, и могут, на выбор — либо забраковать произвольное число готовых задач ("не прошли приемку"), либо потребовать снять кого-нибудь с проекта. Таски выбираются из отдельной колоды с идеями по украшению офиса: вырезать снежинку, раскрасить гномика, сделать гирлянду и т.п. За одну ночь можно подкинуть в бэклог столько тасок, сколько осталось игроков. В начале игры бэклог наполняется тасками по числу игроков x2.
— Команда. Ночью спят, днём выполняют таски из бэклога. Заодно обсуждают, как вообще успеть сделать всё, что навалили, и кого можно выгнать, чтобы уже перестали наваливать. Тот, кого выгоняют, вскрывает свою карту и дальше участвует только как наблюдатель. Во время спринта ("днем") Заказчики работают, как члены команды.
— Продакт-оунер. Просыпается раньше всех, может либо проверить кого-то — не является ли тот Заказчиком, либо выкинуть из бэклога несколько задач, которые ещё не взяли в работу (до половины от числа оставшихся игроков).
— Ресурсный менеджер. Может спасти от снятия с проекта одного из членов Команды, но не дважды подряд. Себя может спасти только один раз.
— Человек-снежинка. Не является Заказчиком, но выигрывает, когда выигрывают они. Никакими специальными умениями не обладает, ночью не просыпается, но старается незаметно парализовать работу команды.
Игра заканчивается победой Команды, если всех Заказчиков выкинули (объявлен фича-фриз и можно спокойно доделать все задачи в работе).
Заказчики (и Снежинки) побеждают, когда Команда полностью разобрана (результат работы им достаётся бесплатно + неустойка).
Пока на практике играть не пробовал, но должно быть весело!
Telegram
Системный сдвиг
Авторский канал Юрия Куприянова. Обучаю системных аналитиков. Пишу про нетривиальные темы в анализе, проектировании систем, управлении и обучении.
Программный директор WAW, член ПК Flow, ЛАФ.
Контакты: @YuryKupriyanov
Курсы: https://systems.education
Программный директор WAW, член ПК Flow, ЛАФ.
Контакты: @YuryKupriyanov
Курсы: https://systems.education
🤔10🔥7⚡2💩2
Пока готовился к открытому уроку нашел очень дельную статью про gRPC от ребят из Тинькоф, если хотете начать погружение в gRPC, то сначала смотрите мой открытый урок https://www.youtube.com/watch?v=8s4QFKO4RmY, а потом читайте статью https://habr.com/ru/companies/tinkoff/articles/780024/
YouTube
Какие сервисы делать на gRPC? // Демо-занятие курса «Системный аналитик. Advanced»
На открытом уроке:
- познакомимся с причинами развития подхода RPC компанией Google, с основными отличиями в подходах к проектированию с классическим REST API;
- получим представление об описании сервисов gRPC и структуры контента, которым обмениваются участники…
- познакомимся с причинами развития подхода RPC компанией Google, с основными отличиями в подходах к проектированию с классическим REST API;
- получим представление об описании сервисов gRPC и структуры контента, которым обмениваются участники…
👍9
https://www.youtube.com/watch?v=RkaRSFsVGrw заскакивайте на эфир к Кате Лысенко
YouTube
Вначале было слово - архитектура от словаря. Екатерина Лысенко
Митап в рамках конференции ARCHDAYS: https://archconf.ru/arch
Описание митапа: DDD учит, что язык - основа всего. Язык должен стать отправной точкой архитектуры. Мы рассмотрим на примерах, как можно выделять контексты и строить архитектуру внутри домена…
Описание митапа: DDD учит, что язык - основа всего. Язык должен стать отправной точкой архитектуры. Мы рассмотрим на примерах, как можно выделять контексты и строить архитектуру внутри домена…
👍1
Всем привет! Новый года я начал просто потрясающе - свалился с лютующим в Португалии гриппом А, кашлем и температурой под 39. Зато появилось время немного притормозить, подумать, переосмыслить.
И первое решение - это все таки начать делать более авторский контент. Да, вначале я буду опираться на чужие материалы, но не как на основу для обзора, а как на подводку к какой то своей мысли, которая мне так или иначе отозвалась. Поэтому я буду очень благодарен вам за любую обратную связь, особенно если она будет конструктивной. Если вам не понравился пост - не стесняйтесь ставить какашку, а если при этом вы еще и напишите, что вам не понравилось - форма или содержание, будет вообще круто.
И первое решение - это все таки начать делать более авторский контент. Да, вначале я буду опираться на чужие материалы, но не как на основу для обзора, а как на подводку к какой то своей мысли, которая мне так или иначе отозвалась. Поэтому я буду очень благодарен вам за любую обратную связь, особенно если она будет конструктивной. Если вам не понравился пост - не стесняйтесь ставить какашку, а если при этом вы еще и напишите, что вам не понравилось - форма или содержание, будет вообще круто.
👌8👍1💩1
И начну с небольшого рассуждения про книги. Думаю, многие видели, что я искренне считаю того же Вигерса сильно устаревшим и вообще не очень полезным современному аналитику, особенно начинающему. Кто то говорит, что он помогает систематизировать знания. Возможно, лично мне не помог, знания лучше не стали, но, может быть - дело во мне.
Я потратил на Вигерса чертову тучу времени и нервов, делал несколько подходов, чтобы его прочитать, наконец осилил целиком, через насилие над собой и тут меня постигло разочарование, описанное выше, знаний не прибавилось, система не построилась. Сложно, долго, нудно.
И есть обратный пример - я точно так же заставлял читать себя Коберна про Use Case,но там мне реально открылась новая вселенная и понимание, что все то, что в банках называют Use Case это дико извращенное понимание методологии и от такого ее использования Коберн открещивался. Я про до жути детализированные Use Case до вызовов API, которые еще иногда и бизнесу носят на утверждение. Там мне истина открылась где то через 50 страниц.
И вот сейчас я смог это отрефлексировать и перестать себя заставлять читать книгу, если не получается ее читать хоть по немного и если за первые 50 страниц ты не понял, зачем оно тебе.
Вот буквально вчера принял решение прекратить мучить "Как пасти котов", которую многие считают очень полезной для организации работы команды разработки, а я же все таки теперь продакт менеджер 😁, с разработкой надо общаться немного по-другому. Но она тоже выглядит устаревшей и насквозь пронизана тем - что вы больше не программист, не надо писать код. За 60 страниц я не увлекся. Скажу сразу, что тот же Скрам, что от Сазерленда, что от Швабера проглотил за несколько дней,хотя написаны они примерно в те же года, так что я не то чтобы не уважаю старшых..
И принял очень правильное на мой взгляд решение - перечитать "45 татуировок менеджера", с которой началось мое увлечение профессиональной литературой. И за два дня, больной и с температурой прочитал 200 страниц. Попутно рефлексируя каждую татуировку. Но это уже в следующих постах.
https://www.labirint.ru/books/872445/ (никакой рекламы, просто первая ссылка)
Я потратил на Вигерса чертову тучу времени и нервов, делал несколько подходов, чтобы его прочитать, наконец осилил целиком, через насилие над собой и тут меня постигло разочарование, описанное выше, знаний не прибавилось, система не построилась. Сложно, долго, нудно.
И есть обратный пример - я точно так же заставлял читать себя Коберна про Use Case,но там мне реально открылась новая вселенная и понимание, что все то, что в банках называют Use Case это дико извращенное понимание методологии и от такого ее использования Коберн открещивался. Я про до жути детализированные Use Case до вызовов API, которые еще иногда и бизнесу носят на утверждение. Там мне истина открылась где то через 50 страниц.
И вот сейчас я смог это отрефлексировать и перестать себя заставлять читать книгу, если не получается ее читать хоть по немного и если за первые 50 страниц ты не понял, зачем оно тебе.
Вот буквально вчера принял решение прекратить мучить "Как пасти котов", которую многие считают очень полезной для организации работы команды разработки, а я же все таки теперь продакт менеджер 😁, с разработкой надо общаться немного по-другому. Но она тоже выглядит устаревшей и насквозь пронизана тем - что вы больше не программист, не надо писать код. За 60 страниц я не увлекся. Скажу сразу, что тот же Скрам, что от Сазерленда, что от Швабера проглотил за несколько дней,хотя написаны они примерно в те же года, так что я не то чтобы не уважаю старшых..
И принял очень правильное на мой взгляд решение - перечитать "45 татуировок менеджера", с которой началось мое увлечение профессиональной литературой. И за два дня, больной и с температурой прочитал 200 страниц. Попутно рефлексируя каждую татуировку. Но это уже в следующих постах.
https://www.labirint.ru/books/872445/ (никакой рекламы, просто первая ссылка)
www.labirint.ru
Книга: 45 татуировок менеджера. Правила российского руководителя - Максим Батырев. Купить книгу, читать рецензии | Лабиринт
Книга: 45 татуировок менеджера. Правила российского руководителя.📙 Автор: Максим Батырев. Аннотация, 🔝 отзывы читателей, иллюстрации. Купить книгу по привлекательной цене среди миллиона книг "Лабиринта" | ISBN 978-5-00195-758-4
🔥8👍5💩3
Буквально за несколько дней проглотил книжку про 45 татуировок. Как писали в комментариях к предыдущему посту, книга не даёт никакой системы или фреймворка для построения эффективной системы управления, но лично я ее не за тем и читаю.
Для меня невозможно взять чужую систему и переиспользовать, невозможно натянуть на себя чужой фреймворк, идёт огромное внутреннее сопротивление, хочется сбросить это ярмо 😁. Звучит смешно и по детски, но так оно есть.
Поэтому книги в формате коротких историй, вредных советов или вот таких принципов мне заходят на ура. Я могу сам выбрать, что принять и отрефлексировать, а что выбросить и пройти мимо и никто тебе не скажет, что ты не прав или без этого вся система не взлетит. Мне, кстати, поэтому и скрам не сильно зашёл, наверное)
Но вернусь к книге. Собственно, она стала для меня первой профессиональной книгой, которую я прочитал, именно она подтолкнула меня к тому, что не только художка может быть интересной и не вся проф литература такая скучная, как методички в универе. И мне очень понравилось то, что я смог сопоставить свои впечатления тогда и сейчас.
Конечно, восторга такого уже нет, но есть такое приятное удовольствие от того, что ты как профессионал можешь согласиться с автором или даже внутренне поспорить, причем обоснованно. И это даёт очень крутую мотивацию.
И одна татуировка у меня с тех самых пор появилась. В книге она идёт под номером два. "Читайте, осмысливайте. Тренируйте главную мышцу".
За прошедшие 5 лет я свою очень неплохо натренировал.
Для меня невозможно взять чужую систему и переиспользовать, невозможно натянуть на себя чужой фреймворк, идёт огромное внутреннее сопротивление, хочется сбросить это ярмо 😁. Звучит смешно и по детски, но так оно есть.
Поэтому книги в формате коротких историй, вредных советов или вот таких принципов мне заходят на ура. Я могу сам выбрать, что принять и отрефлексировать, а что выбросить и пройти мимо и никто тебе не скажет, что ты не прав или без этого вся система не взлетит. Мне, кстати, поэтому и скрам не сильно зашёл, наверное)
Но вернусь к книге. Собственно, она стала для меня первой профессиональной книгой, которую я прочитал, именно она подтолкнула меня к тому, что не только художка может быть интересной и не вся проф литература такая скучная, как методички в универе. И мне очень понравилось то, что я смог сопоставить свои впечатления тогда и сейчас.
Конечно, восторга такого уже нет, но есть такое приятное удовольствие от того, что ты как профессионал можешь согласиться с автором или даже внутренне поспорить, причем обоснованно. И это даёт очень крутую мотивацию.
И одна татуировка у меня с тех самых пор появилась. В книге она идёт под номером два. "Читайте, осмысливайте. Тренируйте главную мышцу".
За прошедшие 5 лет я свою очень неплохо натренировал.
👍11👎2🔥1
Всем привет! Тут нашел гайд, как праввильно делать программное обеспечение с помощью ChatGPT. Гайд короткий и поместрился в один твит, но вот взять из него кусочки и приложить к нашим реалиям проектирования систем вполне можно. https://twitter.com/paraschopra/status/1746942751839797670?utm_source=tldrnewsletter
X (formerly Twitter)
Paras Chopra (@paraschopra) on X
How to use ChatGPT to build software products.
👌1
Это реально лучшая схема BPMN из виденных мной! И самая понятная
Пора возвращаться. Посмотрел интересный доклад "Долой SQL! Или краткий обзор мира нереляционных данных" от Максима Шаламовича и Евгения Асламова. В целом ребята сделали хорощий обзор на базы данных, что и когда использовать. Но самое ценное было, естественно в конце. Ребята оба - архитекторы, и как архитекторы они очень просили аналитиков не приходить с решением в виде схемы БД. Они настаивают на том, что работа аналитика - подготовить логическую модель предметной области, максимум информационную модель в виде диаграммы классов. И, конечно, сценарии использования данных, которые помогут разложить данные правильно.
И я не могу с ними не согласиться. С моей точки зрения - погружаться на такую глубину - работа архитектора, т.е. как правило у аналитика как правил нет нужного опыта и знаний для выбора БД и структуры хранения данных. Многие аналитики вынужденно занимаются такой проработкой, но по факту это уже работа для архитектора и за нее должны платить соответственно. https://www.youtube.com/watch?v=VxV-zwHPOfo
И я не могу с ними не согласиться. С моей точки зрения - погружаться на такую глубину - работа архитектора, т.е. как правило у аналитика как правил нет нужного опыта и знаний для выбора БД и структуры хранения данных. Многие аналитики вынужденно занимаются такой проработкой, но по факту это уже работа для архитектора и за нее должны платить соответственно. https://www.youtube.com/watch?v=VxV-zwHPOfo
YouTube
Долой SQL! Или краткий обзор мира нереляционных данных
Доклад Максима Шаломовича и Евгения Алсамова на конференции Analyst Days #17
27-28 октября 2023. г. Москва Россия
https://www.analystdays.com
27-28 октября 2023. г. Москва Россия
https://www.analystdays.com
👍3👌2
Достаточно занятная статья про гибкие методологии разработки. https://habr.com/ru/companies/magnus-tech/articles/788860/
Читаешь, и в целом чувствуешь боль автора. Я сам как то пытался по скраму в аутсорсе работать, было безумно больно, больше я так не хочу.
Но по прочтении статьи бросается в глаза следующее: автор не понимает и не проникся идеями гибкой управления разработкой ПО, либо специально некооторые ситуации возводит в определнную степень абсурда.
Если тебе нужны гарантированно конкретные фичи к конкретному сроку, то не надо использовать гибкие методологии. Зачем, они реально будут вредить. Ведь гибкие методологии они про решение проблем, а не про фичи и это ключевой поинт. В аутсорсе ты подписываешься под скоупом проекта и сроками с бюджетом. То есть ты можешь сколько угодно внутри проекта быть гибким, но на результат это не повлияет. Так и зачем страдать? Особенно когда заказчик не готов постоянно коммуницировать и участвовать в развитии продукта.
Про несоответствие методологии реалиям разработки - реальная боль, так бывает увы очень часто. Руководитель сказал - внедряем аджайл, послушные исполнители ответили - ЕСТЬ! Проходят треннинги, приглашают коучей, вот только руководитель в этом никак не участвует. И в целом, требует раз в месяц помимо обычных отчетов еще и отчет о внедрении аджайла! При этом сам он не готов меняться. И делегировать принятие решений в команды не готов, тогда никакого аджайла не получится, хотя утренируйся. Все будут страдать, как описывает автор. Кстати, про выбор скрама или канбана - отличное видео от Алексея Пименова https://www.youtube.com/watch?v=NCEqFh5M12M.
Насчет того, что гибкие методологии не учитывают состав и численность команд вообще смешно, особенно учитыаая, что потом идет речь про LeSS. Про то как он в России "не прижился" отлично рассказывает Артем Кротов из Мир Платформ. Про команды в 40 человек - так же странно, всегда можно попилить команды, было бы желание. Вот у нас сейчас как раз пилим команду из 20 человек на 5. Потом расскажу, как прошло.
Про выгорание разработчиков - вообще никакого отношения к методологии, я видел как на них пахали и в водопаде и в "скраме". Аджайл как раз дает возможность сказать, да, мы облажались и потом подумать, почему так случилось. Если причина объективная, то с этим ничего не поделаешь в моменте.
Про нет метрик качества проделанной работы - тут даже комментировать нечего, чем не угодили Acceptance criteria непонятно. Хотя, учитывая, что автор их называет defenition of done, сразу есть вопросики по тому, как люди используют методологию.
В целом - самое странное, что люди все еще пытаются скрестить ужа с ежом и использовать гибкие методологии там, где они скорее будут мешать. Например, в аутсорсе они будут эффективны только при построенных доверительных отношениях с заказчиком и при условии, что заказчик готов уделять много времени на работу с командой, иначе проще для всех работать с ТЗ.
А вы работали в аутсорсе по гибким методологиям? Поделитесь опытом в комментариях!
Читаешь, и в целом чувствуешь боль автора. Я сам как то пытался по скраму в аутсорсе работать, было безумно больно, больше я так не хочу.
Но по прочтении статьи бросается в глаза следующее: автор не понимает и не проникся идеями гибкой управления разработкой ПО, либо специально некооторые ситуации возводит в определнную степень абсурда.
Если тебе нужны гарантированно конкретные фичи к конкретному сроку, то не надо использовать гибкие методологии. Зачем, они реально будут вредить. Ведь гибкие методологии они про решение проблем, а не про фичи и это ключевой поинт. В аутсорсе ты подписываешься под скоупом проекта и сроками с бюджетом. То есть ты можешь сколько угодно внутри проекта быть гибким, но на результат это не повлияет. Так и зачем страдать? Особенно когда заказчик не готов постоянно коммуницировать и участвовать в развитии продукта.
Про несоответствие методологии реалиям разработки - реальная боль, так бывает увы очень часто. Руководитель сказал - внедряем аджайл, послушные исполнители ответили - ЕСТЬ! Проходят треннинги, приглашают коучей, вот только руководитель в этом никак не участвует. И в целом, требует раз в месяц помимо обычных отчетов еще и отчет о внедрении аджайла! При этом сам он не готов меняться. И делегировать принятие решений в команды не готов, тогда никакого аджайла не получится, хотя утренируйся. Все будут страдать, как описывает автор. Кстати, про выбор скрама или канбана - отличное видео от Алексея Пименова https://www.youtube.com/watch?v=NCEqFh5M12M.
Насчет того, что гибкие методологии не учитывают состав и численность команд вообще смешно, особенно учитыаая, что потом идет речь про LeSS. Про то как он в России "не прижился" отлично рассказывает Артем Кротов из Мир Платформ. Про команды в 40 человек - так же странно, всегда можно попилить команды, было бы желание. Вот у нас сейчас как раз пилим команду из 20 человек на 5. Потом расскажу, как прошло.
Про выгорание разработчиков - вообще никакого отношения к методологии, я видел как на них пахали и в водопаде и в "скраме". Аджайл как раз дает возможность сказать, да, мы облажались и потом подумать, почему так случилось. Если причина объективная, то с этим ничего не поделаешь в моменте.
Про нет метрик качества проделанной работы - тут даже комментировать нечего, чем не угодили Acceptance criteria непонятно. Хотя, учитывая, что автор их называет defenition of done, сразу есть вопросики по тому, как люди используют методологию.
В целом - самое странное, что люди все еще пытаются скрестить ужа с ежом и использовать гибкие методологии там, где они скорее будут мешать. Например, в аутсорсе они будут эффективны только при построенных доверительных отношениях с заказчиком и при условии, что заказчик готов уделять много времени на работу с командой, иначе проще для всех работать с ТЗ.
А вы работали в аутсорсе по гибким методологиям? Поделитесь опытом в комментариях!
Хабр
Agile не поможет. Ищем решения острых проблем в разработке
Scrum, Kanban и другие «эталонные» методы ведения проектов далеко не идеальны и многое упускают. Поэтому они редко применяются в чистом виде: как правило, проджекты меняют эти практики под себя. При...
👍7