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

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

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

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

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

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

      Читать дальше →
    • Product Management Digest. Что волнует продуктологов и маркетологов в 2019

        Ежемесячный дайджест новостей российского продуктового сообщества.


        В этом выпуске отчеты про жизнь продуктологов и маркетологов за рубежом The State of Product Leadership 2019 и The 2019 State of Marketing. Множество материалов по Growth Teams. Старт набора в весеннюю программу стартапов от Russol и в бесплатную школу product owner-ов от Додо Пицца.


        Читать дальше →
      • Плотность сюжета в рознице



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

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

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

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



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

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

              — Этот вопрос предлагаю обсудить отдельно. – сказал Евгений Викторович.

              Внезапно, в дальнем конце стола послышалось странное шуршание. Все обернулись на звук и улыбнулись.

              — Ну чего ты свинью несчастную мучаешь! – возмутилась Марина. — Оставь ее бедную задницу в покое!

              — Да, Сергей, что ты делаешь? — достаточно вежливо спросил собственник.

              — Не скажу. — пробурчал Сергей.
              Читать дальше →
            • Об оценке и управлении разработкой программных продуктов

                image

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

                Между тем, этот навык необходим любому программисту ежедневно. Работы всегда больше, чем можно выполнить. Оценка помогает правильно расставить приоритеты, а от каких-то задач вообще отказаться. Не говоря уже о таких бытовых вопросах как бюджетирование и планирование. Неверные оценки, наоборот, создают кучу проблем: заниженные — конфликтные ситуации, переработки и дыры в бюджетах, завышенные — отмены проектов или поиски других исполнителей.

                Справедливости ради следует заметить, что в разработке гораздо более распространены заниженные оценки. Почему? Кто-то считает, что программисты слишком оптимистичны по своей натуре. Я добавлю к этому еще одну причину: быть хорошим программистом и быть хорошим оценщиком — не одно и тоже. Чтобы стать хорошим программистом одного желания не достаточно. Нужны знания и практика. С чего вдруг с оценкой будет по другому?

                В статье я расскажу о том, как менялось мое отношение к оценке задач и как сейчас оцениваются проекты в нашей компании. А начну я с того, как оценивать не надо. Если про то как «не надо» вы уже знаете, переходите сразу ко второй части статьи.
                Читать дальше →
                • +12
                • 4,3k
                • 3
              • Planning poker: заметки о первом впечатлении разработчика

                  Я, как и некоторые другие программисты, не большой любитель митингов. Порой, надоедают все эти sprint refinement, sprint review, retrospective сессии.


                  В командах, где я работала, никогда не было planning poker митингов, но недавно поучаствовала в таком, правда чужой команды. Я знакома со всеми из этой команды (за исключением нового архитектора), но никогда лично не видела полный состав команды в действии, так что с интересом наблюдала за их подходами работы в команде. Помимо того, что было довольно весело, смогла почерпнуть для себя что-то новое и полезное. В этой статье я хочу поделиться своими впечатлениями от участия в planning poker митинге.
                  Читать дальше →
                  • –2
                  • 1,9k
                  • 1
                • Вредные советы: как правильно писать техническую документацию? Часть вторая

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


                    Продолжение руководства нашего технического писателя Андрея Старовойтова, которое поможет сделать вашу пользовательскую документацию проще и понятнее.

                    Начало статьи можно почитать тут, а то, как проходит процесс документирования и локализации наших продуктов мы описывали ранее в этой статье.

                    В этой части мы подробно разберем топики, из которых в основном состоит пользовательская документация (особенно User’s Guide) – а именно task-топики, в которых рассказывается, как решить конкретную задачу.

                    image
                    Читать дальше →
                  • Великий исход из индустрии видеоигр

                    • Перевод

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

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

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

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

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

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

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

                  Самое читаемое