Как стать автором
Обновить
364.07

Управление проектами *

Как заставить всё работать

Сначала показывать
Порог рейтинга

Команда из девяти сотрудников Nokia в 2007 году выступила с внутренней презентацией, на которой объявила, что представленный первый iPhone от Apple может изменить стандарты индустрии и станет лидером рынка.

Согласно выводам инженеров компании, сенсорный интерфейс вместе с безупречной интеграцией интернет-приложений обеспечит непревзойденную простоту использования. По их мнению, Nokia нужно было оперативно разработать собственный сенсорный интерфейс, чтобы не проиграть Apple.

Менеджмент Nokia не прислушался к мнению разработчиков и инженеров, а iPhone вскоре стал новым стандартом в индустрии мобильных устройств. Мобильный бизнес компании Nokia в 2011 году приобрела Microsoft.

Теги:
+2
Комментарии3

Культура и практика написания MoM (minutes of meeting)

Короткий пост о том, что это такое, зачем (и для чего) и, конечно, как.

Тема избита, но хочется поделиться опытом. Вероятно, это болит лишь у меня, но за последние 5 лет я не встречал компанию, в которой MoM был общей практикой. При этом есть очевидная потребность фиксировать историю решений и сформированных устных договоренностей. Так для меня этот пост крик души и возможность напомнить о пользе этой практики.

Что такое MoM (Minutes of meeting)? 🤨

Короткие, тезисные записи ключевых мыслей по результату встречи.

Зачем MoM?

  • Юридическая значимость, если использовать email для фиксации позиций и решений (возможно, в мессенджерах тоже, но в email я уверен)

  • Синхронизация представления о результатах встречи

  • Напоминалка (чтобы вернуться к результатам обсуждения, если потребуется). Вроде записки самому себе в будущем, которая поможет вспомнить обсуждение и ключевые для участников договоренности

Как MoM?

  • Идеально - сразу после встречи (чтобы не забылось)

  • Путь написания письма (email). Вспоминаем пункт про юридическую значимость

  • Коротко - 5±2 тезиса по следующим пунктам. Количество не случайно. Короткий текст воспринимается легче, проще выделить главное и требует меньше времени на создание

    • Кто был на встрече (участники)

    • Что обсуждали (ключевая тема, ответвления) 1±2

    • Что решили (ведь зачем-то собирались?)1±2

    • Задачи, которые появились на встрече. Кто исполнитель и, конечно, дедлайны по ним. Тут ограничений нет.

    • Следующая встреча - требуется ли, дата и время

Стоит упомянуть, что вести MoM задача непростая. Часто бывает, что ведущий заметки для написания MoM может "выпадать" из встречи, особенно если идет жаркая дискуссия. Вероятно, можно решить эту проблему делегируя задачи транскрибирования и саммаразинга техническим решениям ИИ.

Что еще можно почитать на эту тему:

Теги:
+2
Комментарии2

Не делегируете, потому что хотите быть не заменимым?

И это действительно часто оказывается правдой.

Когда предприниматель наконец успешно делегирует свои обязанности, у него высвобождается время. Но что происходит дальше? Привычных задач нет и собственник начинает цепляться за старые дела, которые он стремился передать.

Здесь важно перестроить свою роль и осознать: вы остаетесь важным звеном в компании, но уже в другом качестве. И чтобы сделать рывок:

  • Перестаньте заниматься микроменеджментом

Учитесь сдерживать себя, когда хочется контролировать всё и вся. Не нужно ежедневно контролировать каждый отдел и уточнять детали их работы. Вместо этого научитесь ставить задачи на более долгий срок, например, на неделю, и анализировать итоги на регулярных встречах.
Помните: микроменеджмент изматывает как вас, так и вашу команду.

  • Найдите время для стратегии

Заранее выделяйте несколько часов в неделю на разработку стратегии — как для отдельных отделов, так и для всей компании. В это время отключайте мессенджеры, звонки и сосредоточьтесь на том, как развивать бизнес. Это полезно не только для продуктивности, но и помогает вашей команде быть самостоятельной.

  • Обучайте сотрудников приносить решения, а не вопросы

Каждый раз, когда сотрудники обращаются к вам за решением проблемы, задавайте им вопрос: «А как вы думаете? А что можно сделать?» Это простое правило со временем научит сотрудников думать самостоятельно и приходить к вам с уже подготовленными вариантами действий. Таким образом, вы формируете культуру ответственности в компании.

 Эти простые, но важные шаги помогут перейти вам как собственнику на новый уровень. Вы перестанете вмешиваться в каждую задачу, а сотрудники научатся самостоятельно принимать решения. Помните, без качественного делегирования невозможно добиться стабильного роста бизнеса.

 А теперь подумайте: вы действительно не делегируете, потому что хотите оставаться незаменимым? Или это всего лишь привычка, которая сдерживает ваш рост?

Теги:
0
Комментарии2

Финский университет Аалто опубликовал в открытом доступе цифровой архив Nokia Design Archive с эскизами, рендерами, прототипами, презентациями и рекламными постерами легендарной Nokia — от сырых идей, лежащих в основе культовых проектов, до концепций, которые так и не покинули чертёжную доску.

Теги:
+4
Комментарии0

Если вы решили, что с нового года надо начать читать книги

Если вы тот самый человек, который хочет почитать, то я бы рекомендовала начать год с Даниэль Канемана, "Думай медленно, решай быстро".

Это книга Нобелевского лауреата по экономике, которая рассказывает о нашем мозге и особенностях его (и, соответственно, нашей) работы невероятно дивным языком.

О книге в 18 словах

У нас есть 2 типа мышления — быстрое (интуитивное) и медленное (аналитическое) — они оба влияют на наше поведение и принятие решений. 

Полезность чтения для продакта (и не только для него) 

➛ Поймёте, почему вы и пользователи вашего продукта принимаете те или иные решения.

➛ У вас появятся новые нейронные связи, а это почти равно новым идеям.

➛ Обогатите вашу речь, чтобы писать (документацию) и говорить (с командой), благодаря грамотному и академически точному языку книги.

Прямо сейчас это единственная книга, которую я могу рекомендовать с уверенностью — но имейте в виду, что я совсем не чтец, а только жнец и на дуде игрец.

Зачем вы читаете? Расскажите :)

Теги:
+4
Комментарии0

Система управления проектами для удаленных команд Virex теперь доступна!

Коммуникация, задачи, аналитика, гибкость — всё это про Virex.

Система управления проектами Virex начинается с простоты. Все проекты в одном месте. Все ключевые данные, задачи и прогресс проекта одном экране.

Матрица задач в Virex гибкая. Вы можете настроить процесс работы под себя: бэклог, задачи в процессе и завершённые задачи — всё это легко управляется и визуализируется.

Лента активности Virex: больше не нужно искать, кто, что и когда сделал. Все изменения в проекте собраны в одном месте.

Встроенные чаты для каждого проекта. Общайтесь со своей командой прямо в Virex.

Заходите в Virex прямо сейчас!

https://app.virex.studio

Теги:
+2
Комментарии2
AnythingLLM
AnythingLLM

Лед тронулся, демократизация LLM идет полным ходом. AnythingLLM – это GUI обертка вокруг
Ollama + RAG.

https://anythingllm.com

Ollama в свою очередь является CLI оберткой вокруг другого известного проекта llama.cpp.

А llama.cpp позволяет запускать модельки локально даже если у вас нет GPU.

RAG это соответственно Retrieval-Augmented Generation - метод который позволяет встраивать проприетарные данные в LLM промпт.

Например, берем прайс-листы Электромагнитые муфты ЭТМ 051С-1А и ГОСТ 8966-75 Части соединительные стальные с цилиндрической резьбой. После процессинга сотрудники смогут задавать самые каверзные вопросы о муфтах и ГОСТах, LLM.

Какие то ушлые консалтеры из Германии замутили Helm чарт для AnythingLLM для того, чтобы можно было развернуть его на Kubernetes и используют для решения похожих задач в немецкой госухе (департамент города Габмург?).

https://github.com/la-cc/anything-llm-helm-chart

У это AnythingLLM есть даже REST API, можно использовать его для системной интеграции. Хотя решение это конечно не enterprise уровня. Для такого рода задач нужно, что-то класса MuleSoft или Apache Camel.

Теги:
-1
Комментарии0

Полезные советы от разработчика OpenSearch Даниила Дубровкина из AWS.

Вы смотрели The IT Crowd? Это уморительный британский телевизионный ситком примерно 2006 года, в котором группа ИТ‑гениев работала в отделе технической поддержки Reynholm Industries в Лондоне. Один из характерных смешных моментов заключается в том, что каждый раз, когда звонил телефон, Рой брал трубку и, не дожидаясь ответа, спрашивал: «Вы его выключили и снова включили?», а затем вешал трубку. Я часто чувствую себя Роем, когда общаюсь с пользователями, сообщающими об ошибках в проектах с открытым исходным кодом, которые я поддерживаю.

Вот мой структурированный подход к любым ошибкам (багам, проблемам), о которых сообщают в моих проектах с открытым исходным кодом:

  1. Не исправляйте ошибку. Поскольку это проект с открытым исходным кодом, и мы не продаём программное обеспечение, у сопровождающих может быть некоторая социальная ответственность, но они не обязаны что‑либо делать.

  2. Не пытайтесь воспроизвести ошибку. Не уверены, что это ошибка? Не можете воспроизвести проблему? Вежливо запросите дополнительную информацию или разъяснения.

  3. Не пытайтесь написать тест, который докажет, что это ошибка. Попросите человека, сообщившего о проблеме, попытаться написать автоматизированный и провальный тест. Это поможет сузить круг проблем и гарантировать, что ошибка останется исправленной в будущем.

  4. Не исправляйте ошибку. Теперь, когда человек, сообщивший об ошибке, написал для неё автоматизированный тест, он так близок к её исправлению. Попросите его сделать это. Это дает человеку, сообщившему об ошибке, чувство причастности и вклада в проект.

  5. Не делайте ничего другого. Не можете получить никакого участия в устранении ошибки от человека, сообщившего о ней? Оставьте ошибку открытой. Кто‑то другой её подхватит.

tl;dr Не исправляйте ошибку! У здорового проекта с открытым исходным кодом будет много вовлечённых участников, особенно когда дело касается ошибок. Это один из самых простых плодов, которые вы можете собрать как сопровождающий. Тем не менее, иногда я просто хочу исправить ошибку сам, потому что это так интересно.

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

9 законов программирования для новичков и опытных, без которых невозможно добиться успеха в проекте.

Закон Брукса — если вы посадите трёх кодеров за одну задачу, они не сделают её в три раза быстрее. Чем больше ваша команда, тем сложнее становится координация и планирование.

Закон Гудхарта — чем жестче ваши KPI и метрики для измерения эффективности, тем сильнее они отвлекают от выполнения самих задач. В самых запущенных случаях люди забивают на задачи и переключаются только на KPI.

Закон Хайрама — чем больше у API пользователей, тем сильнее они полагаются на незадокументированные особенности, превращая их в «обязательные» функции. Из‑за этого любые изменения становятся сложными, ведь легко сломать что‑то для тех, кто уже привык к старым фишкам.

Закон Конвея — структура программ часто повторяет организационную структуру команды, которая её создала. Если слепо следовать границам в команде, софт получится неоптимизированным.

Закон Линуса — база опенсора. Чем больше людей проверяют код, тем больше шансов найти ошибку.

Закон Хофтшадтера — дедлайн всегда нужно ставить с запасом. Мы склонны занижать количество времени, необходимое для выполнения задачи.

Закон Кернигана — код всегда должен быть простым и понятным. Сложный код всегда становится неподъёмным в отладке и сопровождении — это только вопрос времени.

Закон Питера — софт‑ и хард‑скиллы, это разные навыки. Так, топовый кодер не обязательно обладает такими же способностями к управлению людьми, руководству командами или выполнению стратегических требований лидерства.

Закон Парето — усилия должны быть избирательными. Чтобы 20% усилий приносили 80% результатов, сначала нужно понять, куда прикладывать эти усилия. Качество всегда перевешивает количество, а результат важнее времени затраченного на задачу.

Теги:
Всего голосов 17: ↑17 и ↓0+20
Комментарии3

Почти универсальные проектные принципы или Как перестать зависеть от методологий — Егор Сизяков / Ural Digital Weekend 2024

1. Что такое NUPP и зачем они нужны?

2. А конкретнее? Разбираем NUPP 1−6.

3. Как их внедрить на практике?

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/SBXix

Теги:
Рейтинг0
Комментарии0

Как создать ценность там, где про неё редко спрашивают — Алексей Мезенцев / Ural Digital Weekend 2024

В докладе Алексей рассказал о том, как в условиях жёстких ТЗ развернуть команду к ценности, как внутри дорожных карт проекта запустить спринты, выстроить циклы доставки на базе сотрудничества с Заказчиком ради повышения ценности продукта.

Ссылка на видео в ВКонтакте.

Ссылка на презентацию: https://goo.su/L1g8Vmv

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Как добиться взаимопонимания между клиентами, менеджерами и программистами — Григорий Кирейчук / Ural Digital Weekend 2024

— Разговоры на одном языке, как мы этого добиваемся

— Визуальные схемы: превращаем сложное в понятное

— Как мы экономим время команды и заказчика на погружение в проект

— Промежуточные презентации и почему они важны

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/hgU2IPF

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Эффективность Шредингера: метрики работы команды разработки, поиск и устранение узких мест в процессах — Полина Таран / Ural Digital Weekend 2024

Эффективность конкретного сотрудника и всей команды, состояние продукта, узкие места в процессе — все эти вещи важно понимать руководителю команды разработки. Но как их понять, опираясь не только на свои ощущения? В докладе Полина разобрала, с какими вопросами сталкиваются тимлиды различных команд разработки и как на них могут помочь ответить метрики.

Ссылка на видео в ВКонтакте.

Ссылка на презентацию: https://goo.su/Tuyca

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Ближайшие события

27 марта
Deckhouse Conf 2025
Москва
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань

Масштабирование под давлением — возможность или вызов?

На этот вопрос в подробностях отвечает бэкенд-инженер и руководитель команды разработки монетизационных продуктов Авито Дмитрий Телепнев. Из его рассказа вы узнаете:

  • как обеспечить рост монетизации по модели cost-per-action;

  • как масштабировать CPA от MVP до 1млн RPM;

  • как подойти к планированию и обеспечить прагматичный подход к исправлению вкупе с продуктовыми инициативами.

Переходите по ссылке, чтобы ничего не упустить.

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Теги:
Всего голосов 14: ↑13 и ↓1+12
Комментарии0

Самоорганизованные команды: формирование, принципы работы, контроль и адаптация под специфику процессов — Алексей Червон / Ural Digital Weekend 2024

1. Что такое самоорганизованные команды?

2. Принципы/устройство их работы.

3. Как построить самоорганизованную команду?

4. Как контролировать/модифицировать ее под свой продукт и процессы?

Ссылка на видео в ВКонтакте.

Ссылка на презентацию: https://goo.su/gq1jv

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Основы Управляемой Эволюции. Как проводить изменения с минимальным сопротивлением — Алексей Пименов / Ural Digital Weekend 2024

Большинство подходов по управлению изменениями предполагают смену парадигмы работы, выработку новых механизмов работы и организационной структуры и убеждение людей в том, что именно это принесет пользу. Результатом таких действий является сильное сопротивление изменениям, о способах борьбы с которыми написаны целые тома. В докладе спикер рассмотрел альтернативный подход к управлению изменениями, который называется Управляемая Эволюция, в котором мы минимизируем сопротивление изменениям. Хотите узнать за счет чего? Слушайте выступление Алексея.

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/wFFb

Теги:
Рейтинг0
Комментарии0

Почему хорошие программисты становятся плохими менеджерами — Федор Борщев / Ural Digital Weekend 2024

В докладе Федор рассказал о том, чем отличается работа руководителя от работы инженера-эксперта, и что у них общего. А также о том, что такое траектория профессионального роста, как выбрать свою и не ошибиться.

Ссылка на видео в ВКонтакте.

Ссылка на презентацию: https://goo.su/eJ3yi

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Синергия тимлида и рекрутера: строим эффективный процесс взаимодействия — Евгений Антонов / Ural Digital Weekend 2024

Существует очень много боли и неудовлетворенности вокруг взаимодействия тимлидов и рекрутеров при найме.

В докладе Евгений рассмотрел разные варианты совместной работы. Рассказал, как ее организовать так, чтобы сузить воронку найма, поскорее заполучить подходящего сотрудника и не ругаться друг на друга.

Показал и прокомментировал конкретные примеры и дам общую схему того, как это в целом может работать. Ведь работа тимлида и рекрутера может быть продуктивной и слаженной.

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/PrYp

Теги:
Рейтинг0
Комментарии0

Управление ликвидностью, интеллектуальные права и bus-фактор собственника — Оксана Плешанова / Ural Digital Weekend 2024

В своем докладе Оксана поговорила о самых важных и неочевидных рисках для бизнеса. На что важно обратить внимание ИТ-компании, чтобы избежать финансовых потерь и краха. Какие есть риски ликвидности и как их избежать, какие интеллектуальные права необходимо защищать ИТ-компаниям. Также затронула превентивные меры защиты бизнеса, о которых зачастую забывают собственники.

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/BUHMk8X

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Организационные изменения компании с ростом бизнеса c 500 до 7500 человек — Константин Мягких / Ural Digital Weekend 2024

В докладе Константин рассказал, как менялась оргструктура Авито с ростом команды с 500 до 7500 человек, какие вехи мы прошли, и как строится целеполагание и быстрая разработка новых продуктов в большой компании.

Ссылка на презентацию: https://goo.su/V1uL6s5

Ссылка на видео в ВКонтакте.

Теги:
Рейтинг0
Комментарии0
1
23 ...

Вклад авторов

Работа