#izhittalks итоги и отзывы

avatar Павел
Овчинников
05.07.2013, 09:39
комментировать

фотография (1)

Вчера в баре BBQ собрались самые мобильные ИТ-менеджеры Ижевска, чтобы затереть за жизнь, работу и что делать дальше. Ожидалось много интересных людей, и ожидание это оправдалось полностью. Получился даже небольшой твит-репортаж под хештегом #izhittalks. А вот получилось ли само мероприятие: для этого сегодня разворачиваем talks уже в комментариях на Ижайти.

Прежде, чем начнется перекрестный обмен мнениями, немножко расскажу о том, как это виделось с моей стороны. Это был, прежде всего, эксперимент с форматом — никто ни к чему не готовился, ничего не продумывал, не парился. А сам формат talks подразумевает стихийность, внезапность и, самое главное, полное отсутствие барьеров. Мне показалось, что некоторые пришедшие на встречу ребята все-таки ждали, что их поведут, начнут модерировать. Поэтому тесная беседа не очень сложилась. Помешало этому так же не очень удачная акустика и веселые гости на втором этаже.

Не смотря на это, мы достигли определенных целей. Главное, поняли, что в Ижевске есть ИТ-менеджеры, готовые общаться, делиться, тусоваться. Это значит, что мы будем продолжать работу с этой аудиторией. Будет понятно, если кто-то не совсем раскусил фишку talks и на следующих встречах не появится. С другой стороны, сам формат не очень подходит к массовой тусовке. В общем, будем продолжать встречаться, возможно, более камерно и с более узкими темами для разговоров. Может быть, приглашать кого-то для коленочных мастер-классов в каком-нибудь экспресс-формате.

А теперь вы. Кто был, что предлагаете, темы, советы, пожелания, замечания, когда в следующий раз — лейте в комментарии. Это #izhittalks.

Не скупитесь на ретвиты ↓
  • Timur Minnakhmetov

    То что ИТ-менеджеры готовые общаться в городе есть вроде было и так известно.

    А еще какие результаты? Поговорили, рассказали о своих проектах, выпили и разошлись?

  • Veronika Rupasova

    Побуду капитаном Очевидность, но тем не менее:

    1. в следующий раз для таких мероприятий все-таки имеет смысл снимать конференц-зал. Желательно — с проектором.

    2. Для первого пробного мероприятия было нормально, но для следующих было бы интереснее обозначать более узкие и конкретные темы. Под которые адресно приглашать конкретных докладчиков. Например, лично мне было бы интересно послушать Виктора Вагина (РИТ) и кого-нибудь из НПО Компьютер по опыту внедрения той же скрам-методологии (простите, я понимаю, что я уже всех задолбала, но вчера предметного разговора на эту тему так и не случилось). Или еще вчера краем уха слышала фразу Андрея Подкина про то, что в пост-продакшн эффективен Kanban, вот про его опыт в этой теме тоже интересно послушать. Считайте, что это мой «заказ»)))

    • vva

      рассказать конечно можно, тем более я в разных составах/вариантах это дело наблюдал в 3-4 воплощениях :) но это будет не совсем success story, а в том же ключе «что получается, а что не очень получается». ну и мне больше есть чего рассказать на данный момент в плане как было сказано на предыдущем докладе «прикрыться договором» :)

      • Veronika Rupasova

        а тут как раз-таки и интересует, что получается, а что не очень. Я, честно говоря, не очень люблю success story в чистом виде. Меня больше анализ проблем волнует. Я негативист, наверное))))))

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

        • vva

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

          • Veronika Rupasova

            не-не, интересно и то, и другое. Просто, видимо, это должны быть разные узко-тематические встречи.

    • http://twitter.com/apodkin Andrew Podkin

      >> кого-нибудь из НПО Компьютер по опыту внедрения той же скрам-методологии

      Те люди в НПО, которые много шишек на скраме набили, не ходят на подобные тусовки, к сожалению.

      Если интересны unsuccess stories, могу рассказать, как лет 9 назад я пытался в НПО внедрять элементы XP.

      >> еще вчера краем уха слышала фразу Андрея Подкина про то, что в пост-продакшн эффективен Kanban, вот про его опыт в этой теме тоже интересно послушать

      Пока у меня опыт в канбан только на уровне исполнителя. Поэтому если не горит, то предлагаю подождать, пока я сам организую пост-продакшн на канбане и тогда уже расскажу :-)

      • Veronika Rupasova

        >>Те люди в НПО, которые много шишек на скраме набили, не ходят на подобные тусовки, к сожалению.

        Будете смеяться, но я тоже обычно на подобные тусовки не хожу))) Вот чесслово, много лет меня никто ни на одной местной ИТ-тусовке не видел. А вообще, если серьезно, мне кажется, что это вопрос переговоров со стороны организаторов мероприятия. Если будет четкая тема и адресное приглашение, то вполне вероятно, что можно уговорить.

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

        • vva

          основная проблема которую решает Agile: отсутствие регулярного и качественного общения stakeholder/команда. как сказал (утрируя) Шемякин на состоявшемся докладе: дали команду, сказали делай что хочешь. или как сказал Плетнёв: заказчик дал денег и через полгода начал спрашивать «ну как?». действительно при таком подходе руководства/заказчиков Agile себя показывает, бо приучает регулярно и думать и отчёты писать. далее всякие отдельные частные практики которые решают уже несколько иные задачи (канбаны, TDD и прочие estimation poker ы). Есть задачи которые могут достигаются опосредованно типа мотивации команды (если stakeholder заинтересован или если сами не дураки). На мой взгляд в общем то и всё. Ни скорости разработки, ни какой то повышенной «гибкости» Agile по моему опыту не даёт.

          • Veronika Rupasova

            ну вот давайте и поговорим об этом, конкретно и с примерами. У нас в конторе есть две несвязанные между собой проблемные ситуации:

            1. есть постоянный долговременный западный заказчик, который сам выступил с инициативой внедрения Agile, сертифицировал скрам-мастеров (хотя конкретно эта сертификация для меня пока тоже под большим вопросом). И есть пара его проектов, на базе которых мы совместно пытаемся эту метолодогию типа внедрять))) Пока видимых результатов не наблюдается, но уже очевидны некоторые шишки и узкие места.

            2. есть стартапный инвестиционный проект, в котором в роли Product Owner выступает не внешний заказчик, а мы сами (если угодно, конкретно я). Для меня сейчас важно понять, стоит ли в принципе трепыхаться в сторону Agile, т.е. могу ли я получить какие-то бонусы от этого (со стороны мотивации ли, контроля, организации разработки или чего-то еще). И если да, то на каких конкретно аспектах Agile стоит концентрироваться. Потому просто внедрять Agile as is просто для того «чтобы былО», понятное дело, не интересно. Сектантство — не моя стезя)))

            • http://twitter.com/apodkin Andrew Podkin

              >> Потому просто внедрять Agile as is просто для того «чтобы былО», понятное дело, не интересно.

              Конечно. Agile — это инструмент. Точнее класс инструментов. Вам будет интересно применять молоток или кувалду просто чтоб былО? Или вы все же будете подбирать инструмент к задаче? ;-)

              • Veronika Rupasova

                ну я про то и говорю.

            • vva

              а каких результатов от agile ждёт ваш заказчик и каких — вы в своём проекте?

          • http://twitter.com/apodkin Andrew Podkin

            >> основная проблема которую решает Agile: отсутствие регулярного и качественного общения stakeholder/команда. как сказал (утрируя) Шемякин на состоявшемся докладе: дали команду, сказали делай что хочешь. или как сказал Плетнёв: заказчик дал денег и через полгода начал спрашивать «ну как?».

            И они, и Андрей Гребнев как раз говорили об обратном. Приведенные ситуации — это совсем на Agile.

            • vva

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

              • http://twitter.com/apodkin Andrew Podkin

                >> смотрит заказчик регулярно на то что получается — agile

                Это необходимое, но не достаточное условие. Например, у меня на проекте сейчас заказчик максимально вовлечен. Но все-таки там совсем не agile (точнее там не скрам, не XP, не agile-RUP и не канбан, а других гибких методологий я не знаю).

                >> не смотрит — не agile

                Да. И если заказчик не хочет смотреть, его никаким agile не заманишь.

                • vva

                  вот... не говори так про слона, а то у тебя его никто не купит... если заказчик вовлечён и регулярно смотрит, если команда вовлечена — рисуй шашечки, и говори что самый настоящий agile

          • Rashid80

            За TDD надо бить, лучше сапогами ...

            • vva

              ? почему?

              в mysql TDD

              • Rashid80

                я про Test Driven Development

                • vva

                  ну я опять же не особо в курсе догматический грани между широким использованием автоматических тестов и TDD, но в куче довольно успешных проектов-продуктов тесты используются очень широко и именно в духе Test Driven Developmnet. Конечно всегда можно сказать что есть удобные и неудобные, важные и неважные для тестов места

            • http://twitter.com/apodkin Andrew Podkin

              TDD — это всего лишь инструмент. Давайте тогда еще будем бить сапогами всех, у кого есть микроскоп, а не только тех, кто им гвозди забивает.

              • Rashid80

                Это не инструмент — это тупо выкинутое время/деньги

                • http://twitter.com/apodkin Andrew Podkin

                  Для вас — конечно. Но есть люди, которые умеют это применять и получать от этого пользу.

                  • Rashid80

                    да-да, это такая мантра у TDD'шников )))

                    Я не против тестов, я против их создания ДО кода, потому как в процессе написания кода очень часто выясняется что надо сделать все не так как задумано в начале, под новую задумку переписываются тесты и код пишется дальше. Вопрос: нафига было тратить время на создание тестов в начале? Есть нормальный паттерн: сделать некую функцию/модуль и обложить это тестами. А TDD — это трата времени и забивание мозгов джуниоров дурью ...

                  • Rashid80

                    Я правильно понимаю что вы просто разработчик, который без ведома ПМ и Заказчика тратит драгоценное время проекта ради своих убеждений/пристрастий к TDD?

                    • http://twitter.com/apodkin Andrew Podkin

                      Нет.

                      1. Я не просто разработчик.

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

                      3. У меня нет убеждений/пристрастий к TDD. Инструменты я использую не тогда и не потому, что они мне нравятся, а тогда и потому, что они подходят в конкретной ситуации.

                      И на сладкое:

                      4. Там, где я использовал TDD (а это было далеко не везде), PM, заказчик и QA были довольны качеством итогового продукта.

                    • Rashid80

                      1. Вы P.M. или тимлид?

                      2. Согласовывалось наличие тестов или их написание До создание основного кода?

                      3. В какой ситуации без TDD не обойтись?

                      4. А без TDD не получилось бы удовлетворить всю эту группу? Почему?

                    • vva

                      1. в разных проектах — по разному

                      2. в разных проектах — по разному

                      3. когда нужна гарантированная надёжность (например при разработке СУБД или критичных сервисов)

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

                    • http://twitter.com/apodkin Andrew Podkin

                      1. В тех случаях я чаще всего был тимлидом.

                      2. И то, и другое.

                      3. В той, когда тимлид и команда так решат. Там слишком много нюансов, чтобы вывести какое-то одно краткое правило.

                      4. История не терпит сослагательного наклонения. Я не знаю лучше или хуже были бы тогда результаты при изменении тех или иных факторов.

        • Дмитрий Плетнев

          Вероника, ну тут надо понимать, когда мы привозили спецов из Мск, которые съели собаку на Скрамо-аджайлах, рассказывали про хитрости и удачный и не очень опыт — тупо никто не пришел на это мероприятие.

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

          Сейчас была задача понять — надо это кому-то или нет. Благо людей с опытом, не ижевских, хватает.

          • Dmitri Plotnikov

            Расскажите об опыте проведения проведения платных тренингов, мы в свое время решили все делать бесплатным.

            Тот же НПО не так давно привозил Асхата Уразбаева, и это было бесплатно и качественно.

            Для того чтобы подтянуть матчасть, есть полезная и бесплатная книга от Бориса Вольфсона «Гибкие методологии разработки» dl.dropboxusercontent.com...%D0%BA%D0%B8.pdf

          • vva

            на призыв «мы привезли очень крутых» уже мало кто откликается. а вот на последний призыв «мы привезли ДЛЯ очень ...» люди ещё ведутся...

      • Veronika Rupasova

        >>Пока у меня опыт в канбан только на уровне исполнителя. Поэтому если не горит, то предлагаю подождать, пока я сам организую пост-продакшн на канбане и тогда уже расскажу :-)

        Ок, согласна))

  • http://twitter.com/apodkin Andrew Podkin

    А я бы еще хотел пообщаться (в первую очередь послушать) о продуктовых проектах (о заказных я уже послушал очень много).

    • Дмитрий Плетнев

      Продуктовиков могу вытащить из москвы, какие вопросы к ним будут? О чем говорить?

      • Dmitri Plotnikov

        У нас есть СКБ Контур, думаю ребят вытащить будет проще, и опять же бесплатно на конференцию. Конечно при условии, если будет не жалко делиться пиаром ;)

        • Дмитрий Плетнев

          Разницы особой нет, есть много милых людей, способных про продукт рассказать за билеты и еду)

          • Dmitri Plotnikov

            Да, я как раз про это и говорю. Но нелюбовь к Контуру проскальзывает :)

            • Дмитрий Плетнев

              Дмитрий, ну тут 2 варианта — первый сидеть и думать кто кого не любит. Можно еще спросить — кто любит ЦВТ) Можете и готовы что-то сделать — давайте обсуждать. Нет — ну ок.

              • Dmitri Plotnikov

                Насчет Контура это и было предложение, у нас (IzhDevCom) есть с ними определенные договоренности.

                Запишите это куда-нибудь. Когда будут конкретные предложения по следующему ивенту, можно будет рассуждать еще более предметно о теме доклада и т.д.

        • http://trurl123.blogspot.com/ Andrey Lapin

          Да, нас можно вытащить. :)

      • http://twitter.com/apodkin Andrew Podkin

        В первую очередь мне интересно:

        — Кто должен быть заказчиком на проекте? А кто ни в коем случае не должен им быть?

        — Как надо проводить аналитику на продуктовых проектах? Когда нет человека, который говорит: «Этот софт нужен мне».

        • Дмитрий Плетнев

          Тут надо продуктовиков-аналитиков вытаскивать, тоже есть варианты.

  • Владислав Стерлин

    Хорошо что собрались. Соглашусь что нужны узкие темы.

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

    — Интересно послушать кто и как мотивирует команду на результат. Как распределяется финансовая ответственность среди команды (пряники и кнуты).

    — Тестирование и контроль качества (веб- и мобильная разработка), кто и как подходит к нему (ответственность разработчика, ответственность тестера, ответственность менеджера).

Get Cloud PHP Hosting on CatN