Рубрика «управление проектами» - 74

в 9:23, , рубрики: agile, arrival, okr, scrumtrek, wrike, Блог компании Яндекс.Деньги, доклады, пиэмная, продакт, проджект, Управление продуктом, управление проектами, целеполагание, яндекс.деньги

«Пиэмы не нужны» и ещё три идеи по управлению проектами - 1

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

Со всей страны собрались любители внедрить эджайл, а за ним канбан; они на кухнях обычно делятся сакральным знаньем по вечерам. Вы догадались уже, наверное, к чему до ката весь этот текст. В Яндекс.Деньгах провели «Пиэмную», где не осталось свободных мест.

Зачем быть продактом (или проджектом), секрет успеха крутых команд, о жизни бизнеса были очерки, и как разруливать местный ад — для тех, кто не был, всё-всё записано, там знаний с опытом прям гора. Включайте фоном, как в телевизоре.

Читать полностью »

в 13:33, , рубрики: Bad news, безопасная разработка, команда разработки, менеджмент проектов, ошибки, плохие новости, управление персоналом, управление проектами, управление разработкой

Хочу поговорить о таком важном качестве, как ответственность за ошибки, как свои так и команды.

Одно из самых сложных и неприятных, на мой взгляд, решений для разработчика или руководителя (да да это всегда сложно), это обнаружив свою ошибку на проде или в вот-вот готовящемся выйти релизе, пойти и сказать руководству — “Я ошибся. Ошибка на проде, сейчас я пытаюсь понять, насколько это влияет на пользователей.”

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

Почему нужно рассказывать о таких случаях, если вы разработчик?

Казалось бы, ошибка, на проде, нужно исправить и в следующем релизе спокойно это вылить, зачем беспокоить руководителя?

А вы приносите плохие новости руководству? - 1

Читать полностью »

в 12:08, , рубрики: администрирование, Блог компании Мосигра, настольные игры, розница, управление проектами

Плотность сюжета в рознице - 1

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

Самый фееричный случай был на Меге Белой даче. Мы там заказывали дополнительный банковский терминал. А надо сказать, что в прошлый раз инженер банка оставил нам служебную флешку. На этот раз терминал оказался смонтирован в другой магазин, «Республику игр». Это парни, которые торговали дисками, а теперь торгуют вообще всякими развлечениями.

Мастер пришёл, спросил, они ли настолками торгуют (а они торгуют, причём нашими), поставил терминал. Потом позвонил региональному координатору, сказал, что всё ок. Два дня терминал работал у республиканцев. Потом они заметили, что выручка к ним не попадает. А наши продавцы уже спросили опять, когда уже будет терминал-то. Итог: все те, кто расплачивались у них, переводили деньги к нам. Мы, конечно, потом дорогим партнёрам это всё отдали. На всякий случай переспросив пару раз, на какое юрлицо. Тяжелее всего было сохранять серьёзное выражение лица при этом. Что они сказали банку — мне особенно интересно.
Читать полностью »

в 7:08, , рубрики: автоматизация, Блог компании КРОК, документ, проект, пусконакладка, управление проектами, эксплуатация

Я хочу рассказать про то, как мы продолжаем убивать бумажный документооборот. Одна из областей, которая сдалась совсем недавно, — это технический документооборот, то есть все бумаги, которые нужны в процессе проектирования, строительства и других стадий жизненного цикла любого объекта. Давайте представим, что вам нужно построить башню. Это примерно то же самое, что строить Тёмную башню, но куда мрачнее по уровню бюрократии.

Документы на здание: маленькие радости автоматизации на примере Тёмной башни - 1

У такого строительства — даже если это Тёмная башня — есть чёткий (но довольно большой и сложный) процесс. Одни документы перетекают в другие, например, начинается всё с инженерных изысканий, потом появляется эскиз, потом сам проект, разрешения, вот уже сметы, служебные записки с замечаниями про то, что бак нашей башни не так отштукатурили и так далее. И в конце — регламенты и инструкции по эксплуатации.

Итак, башни еще нет, а документооборот уже есть, и он появляется задолго до строительства. Но уже с этапа возникновения идеи башни может использоваться наша система технического документооборота.Читать полностью »

в 18:28, , рубрики: выгорание, карьера, Карьера в IT-индустрии, кранчи, разработка игр, управление проектами
image

История о том, как Фрэнк Д'Анджело попал в индустрию видеоигр, трогательна и типична одновременно.

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

Классический пианист Д'Анджело думал о том, как можно превратить свои хобби в карьеру — он начал участвовать в жизни онлайн-форумов о музыке в видеоиграх, записал и выложил онлайн больше 200 партитур разных игровых мелодий. На последнем курсе обучения звукотехнике в 2010 году его наняла интерном компания Volition, работавшая над Saint’s Row и Red Faction Armageddon. «Это была карьера моей мечты», — рассказывает Фрэнк. «Наверно, это был самый счастливый для меня момент — результат многих лет движения к цели и её достижение».

Оглядываясь назад, Д'Анджело говорит, что считал это событие концом своих трудностей, но оно оказалось самым началом. «Я был наивен, считал, что после попадания в индустрию всё встанет на свои места. На самом деле это оказалось самым простым», — говорит он.
Читать полностью »

в 10:39, , рубрики: Apache, Firefox 3.6, GIL, nginx, open source, python, деградация программного обеспечения, Проектирование и рефакторинг, Управление продуктом, управление проектами

В книге «Электромагнитная эпоха: работа, любовь и жизнь, когда роботы правят миром» Робин Хэнсон кратко обсуждает деградацию программ:

Программное обеспечение изначально было разработано для одного набора задач, инструментов и ситуаций. Но оно медленно изменяется, чтобы справиться с постоянным потоком новых задач, инструментов и ситуаций. Такой софт становится более сложным, хрупким, в него труднее вносить полезные изменения (Леман и Биледи, 1985)1. В конце концов, лучше начать всё сначала и написать с нуля новые подсистемы, а иногда и полностью новые системы.

Я уверен, что это правда. Как правило, грамотная адаптация программного обеспечения к новым условиям занимает больше времени и усилий, чем написание нового программного обеспечения с нуля. Программисты не любят признавать это, но доказательства очевидны. В проектах open source есть несколько известных примеров.
Читать полностью »

в 6:08, , рубрики: Карьера в IT-индустрии, Карьерные стероиды, управление персоналом, управление проектами, Читальный зал

Метод карьерного роста «Путь Самурая» как-то язык не поворачивается назвать стероидом, потому что он… Не знаю, правильный, что ли. Честный, настоящий, добрый и пушистый.

Потому в жизни встречается не очень часто. Я смог вспомнить только четыре примера, и не все они из моей личной практики, но эти истории я видел своими глазами. Разумеется, люди, о которых пойдет речь, никогда не читали «Хагакурэ» (кодекс самураев), но их истории, поведение, принципы и подходы лежат очень близко к философии древних японских воинов.

Карьерные стероиды. Путь Самурая - 1

Для начала немного расскажу о самураях и их философии.Читать полностью »

в 13:53, , рубрики: Citrix Sharefile, DropBox, google drive, onedrive, облачные сервисы, управление проектами, управление разработкой, хранение данных, хранилища данных

Выбираем систему хранения файлов для командной работы - 1

Мы работаем с большими объемами медиа данных: видео, рендеры, фото, иллюстрации. Чтобы обеспечивать коллективную работу, нам нужен постоянный общий доступ ко всем этим файлам.

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

Мы сравним популярные облачные хранилища для бизнеса: Google Drive, DropBox, Citrix ShareFile и Microsoft OneDrive.

Наши требования к облачному хранилищу:

  • Безлимитный объем данных — у нас много данных, в среднем около 10ТБ. Не хочется постоянно думать сколько нужно докупить места в этом месяце и почему вдруг кончилась квота.
  • Версионность файлов и логирование — git приучил нас, что все изменения можно видеть и откатить. Поэтому и с файлами должны быть точно так же: любое изменение, удаление должно быть обратимо и легко контролироваться.
  • Права доступа — никаких больше общих папок доступных всем. Каждый сотрудник должен иметь свою область видимости.
  • Upload без регистрации — клиенты не должны больше искать файлообменники, чтобы прислать нам тяжелый файл. Файлы должны сразу загружаться в наше хранилище без промежуточных сервисов.

Читать полностью »

в 18:47, , рубрики: basecamp, BillSpring, Firefox, FogBugz, FreshBooks, glitch, gmail, Inbox, Lean UX, mozilla, netscape, open source, Trello, Visual Studio, vs code, Wasabi, золотые наручники, Проектирование и рефакторинг, Управление продуктом, управление проектами

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

Шесть историй, как код переписали с нуля - 1

«Исходный код словно заржавел!» — Джоэл Спольски

Почти два десятилетия назад Джоэл Спольски устроил разнос Netscape за то, что она переписала кодовую базу браузера, в своём эпохальном эссе «Чего никогда нельзя делать». Он пришёл к выводу, что функционирующий софт абсолютно никогда не следует переписывать с нуля. У него было два основных аргумента:

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

Читать полностью »

в 11:43, , рубрики: guidelines for users, technical guidelines, Блог компании Parallels, техническая документация, технический писатель, управление проектами, управление разработкой

Советы по грамотному написанию технической документации для пользователей.
Часть 1

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

На этот раз под катом – руководство нашего технического писателя Андрея Старовойтова, которое поможет сделать вашу документацию для пользователей проще и понятнее (описанные приемы применяют при документировании своих продуктов Apple, Microsoft и другие компании).
Читать полностью »

1...1020...737475...8090...411
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js