Алексей Лустин. Непрерывная проверка качества кода.ScrumTrek
Я расскажу о нашем двухлетнем опыте использования инженерной практики «Continious Inspection» и платформы SonarQube при организации кросс-языковой разработки в процессе «непрерывной поставки» (CI-CD для языков Java, C#, JavaScript, typeScript и Gherkin) при автоматизированном code-review.
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
Олег Бунин, 20 рисков, которые необходимо учесть при расчёте сложного проектаScrumTrek
Десять лет моя команда разрабатывает сложные высоконагруженные проекты. Крупный проект характеризуется, в первую очередь, большой трудоёмкостью, это могут быть десятки человеко-лет! И ошибка в начальных расчётах может дорого стоить разработчику. За десять лет мы столкнулись, наверное, со всеми рисками, которые только могли возникнуть. Так как наступать на грабли повторно не хочется никому, мы все собрали, систематизировали и разработали чек-лист подобных рисков, который я и представлю в докладе. Приходите, это поможет вам не терять деньги, если вы разработчик. И время, если вы заказчик.
В докладе я раскрою бизнес-процессы расчёта стоимости, начиная от работы аналитиков и заканчивая передачей задач в разработку. Когда должен подключаться тимлид? Каковы требования к описаниям задач для программистов? Какие восемь инфраструктурных задач необходимо добавить? 12 статей расходов, которые обычно забывают. Как перевести объём проекта в стоимость? Умножить на стоимость человека-часа? Этого мало :) Ответы на все эти вопросы будут в моём докладе.
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
Антон Бевзюк; Матвей Григорьев. Domain Driven Design: строительные блоки, цем...ScrumTrek
Мы знаем, как важно разговаривать с бизнесом на едином языке и отражать эти знания в коде. Но как отразить эти знания в объектах максимально просто? Из каких блоков построить удобный домен? В докладе мы разберемся с Сущностями, Репозиториями, Value-объектами, Сервисами и другими типами объектов, упрощяющими создание доменной модели. Осторожно: много кода и технических деталей. Разработчики всех мастей, ждем вас. Менеджеры, вас ждет секция про мотивацию и подбор команды :)
Алексей Лустин. Непрерывная проверка качества кода.ScrumTrek
Я расскажу о нашем двухлетнем опыте использования инженерной практики «Continious Inspection» и платформы SonarQube при организации кросс-языковой разработки в процессе «непрерывной поставки» (CI-CD для языков Java, C#, JavaScript, typeScript и Gherkin) при автоматизированном code-review.
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
Олег Бунин, 20 рисков, которые необходимо учесть при расчёте сложного проектаScrumTrek
Десять лет моя команда разрабатывает сложные высоконагруженные проекты. Крупный проект характеризуется, в первую очередь, большой трудоёмкостью, это могут быть десятки человеко-лет! И ошибка в начальных расчётах может дорого стоить разработчику. За десять лет мы столкнулись, наверное, со всеми рисками, которые только могли возникнуть. Так как наступать на грабли повторно не хочется никому, мы все собрали, систематизировали и разработали чек-лист подобных рисков, который я и представлю в докладе. Приходите, это поможет вам не терять деньги, если вы разработчик. И время, если вы заказчик.
В докладе я раскрою бизнес-процессы расчёта стоимости, начиная от работы аналитиков и заканчивая передачей задач в разработку. Когда должен подключаться тимлид? Каковы требования к описаниям задач для программистов? Какие восемь инфраструктурных задач необходимо добавить? 12 статей расходов, которые обычно забывают. Как перевести объём проекта в стоимость? Умножить на стоимость человека-часа? Этого мало :) Ответы на все эти вопросы будут в моём докладе.
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
Антон Бевзюк; Матвей Григорьев. Domain Driven Design: строительные блоки, цем...ScrumTrek
Мы знаем, как важно разговаривать с бизнесом на едином языке и отражать эти знания в коде. Но как отразить эти знания в объектах максимально просто? Из каких блоков построить удобный домен? В докладе мы разберемся с Сущностями, Репозиториями, Value-объектами, Сервисами и другими типами объектов, упрощяющими создание доменной модели. Осторожно: много кода и технических деталей. Разработчики всех мастей, ждем вас. Менеджеры, вас ждет секция про мотивацию и подбор команды :)
Евгений Джамалов. Agile в условиях мульти-вендорности и распределённых команд.ScrumTrek
Мы запустили 12 команд за 9 месяцев. У нас дружат 7 вендоров. Разрабатываем 4 больших продукта. Люди разбросаны по 7-ми локациям. В команде может быть до 4 представителей вендоров. Как минимум, по 1 человеку от другого вендора в команде. Сказка? Этот доклад о том, как мы их "дружили" и синхронизировали. Мой опыт и доклад интересны тем, что я столкнулся с проблемой, которой не было найдено никакого решения в свободном доступе. Мне хотелось бы в формате сказки, поделится с вами тем, как именно мы строили нашу работу и отношения для достижения результата, а так же рассказать, как и почему мы оказались в такой ситуации. К сожалению, много придётся оставить за кадром... так что - спрашивайте!
Сергей Смирнов (Altair Engineering Inc.) | Организация работы распределенной ...RIF-Technology
В рамках доклада рассмотрим вопросы формирования команды с помощью модели МакКинси 7с (McKinsey 7s), поговорим о процессах разработки программного продукта, системе релизов, системном инжиниринге и рекомендациях по системе управления процессами.
Выступление будет интересно руководителям команд разработчиков, особенно тем, кто фокусируется на предсказуемости сроков и качестве создаваемого решения.
"Этот код плохой, его нужно переписать". Слышали? Как обосноватьMaksym Bezuglyi
Как на языке бизнеса доказать необходимость переписывания кода. Как бизнес может объяснить инженерам, что этого делать не нужно, либо как сделать это правильно с перспективы бизнеса.
В презентации:
• Что такое Концепция требований, для чего она нужна и что туда должно войти?
• Какие техники сбора и анализа требований можно использовать на старте проекта?
• Как можно формировать ТЗ к такому проекту и что туда должно войти?
• Какие моменты нужны учесть и какие инструменты можно использовать при управлении требований?
* Показаны и рассказаны реальные примеры докладчика.
Александр Сербул. Прикладное XP в «1С-Битрикс»: как развивать продукт более 1...ScrumTrek
В компании «1С-Битрикс более 10 лет успешно используется плеяда Agile методологий как для управления продуктом, так и для развития технологической платформы: от XP до Model Storming и Story Mappings, от глубокого проникновения всех «бойцов» общими командными целями и интенсивных визуальных коммуникаций без ТЗ, до выполнения топ-менеджерами компании интегрирующих ролей Scrum Master/ProductOwner, вплоть до парного программирования с генеральным директором. Самобытное и глубокое проникновение в культуру команды принципов Agile Manifesto, уважение клиента, возведенное в культ, с искренним желанием решить его технологические задачи, практическое стремление к техническому совершенству. Мы расскажем об этом, поделимся собственным опытом и инструментами, расскажем что работает лучше и когда, а что не взлетает ни при каких условиях. Особое внимание уделим особенностям применения Agile к задачам, требующим глубокого системного анализа и проектирования.
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...RIF-Technology
Самый большой проект, с котором сталкивалась наша команда занял у нас порядка 70 человеко-месяцев, к концу в проекте было около 9000 тикетов, объединённых в 318 эпиков. Объём технического задания превышал 1000 страниц. Как мы справились с этим довольно небольшой командой? Один менеджер, один аналитик, несколько разработчиков.
Нам помогли бизнес-процессы или попросту жёстко прописанные workflow для любой ситуации, любого вида задач или входных данных. Как задача обрабатывается аналитиком, когда она попадает программистам, когда пишется технический дизайн. Как эта схема накладывается на тикетную систему, как использовать эпики и задачи. Все эти правила мы выписали болью ошибок в планировании (и финансах) и я уверен, что они могут сэкономить вам несколько месяцев собственных опытов.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
Методы разработки качественного и чистого кодаIvan Novikov
Доклад на третьем митапе сообщества http://tver.io о том, почему не может существовать TDD в классическом виде, какие возможности преподносят нам использование суррогатных объектов и как отнестись к подходу скептично и использовать лучшие практики, которые метод разработки через тестирование привнес в инженерию ПО.
Доклад на hotcode.org о инструментах и методиках которые помогают нам повышать и следить за качеством PHP кода.
Среди затронутых тем:
- Стандарты в коде
- Средства для статического анализа кода.
- Git хуки
- Непрерывная интеграция
- IDE
- Code review
Как учиться в вузе, заниматься предпринимательством и не умереть в процессеMIkhail Neverov
Данная презентация использовалась для сопровождения лекции для русской группы Высшей IT-школы ТГУ.
Какие цели я преследовал в рамках своей презентации:
Рассказать про то, как можно отучиться в ТГУ, попробовать себя в бизнесе и не умереть в процессе
Приоткрыть завесу в разные аспекты профессиональной деятельности в сфере компьютерных наук
Рассказать как выглядит (и может выглядеть) современный IT-бизнес с моей точки зрения
Какие навыки нужны программисту, а какие - предпринимателю
Семён Факторович (Noveo) рассказывает о карьерных лестницах и различных профессиях в IT-индустрии, 20.02.2013
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
Евгений Джамалов. Agile в условиях мульти-вендорности и распределённых команд.ScrumTrek
Мы запустили 12 команд за 9 месяцев. У нас дружат 7 вендоров. Разрабатываем 4 больших продукта. Люди разбросаны по 7-ми локациям. В команде может быть до 4 представителей вендоров. Как минимум, по 1 человеку от другого вендора в команде. Сказка? Этот доклад о том, как мы их "дружили" и синхронизировали. Мой опыт и доклад интересны тем, что я столкнулся с проблемой, которой не было найдено никакого решения в свободном доступе. Мне хотелось бы в формате сказки, поделится с вами тем, как именно мы строили нашу работу и отношения для достижения результата, а так же рассказать, как и почему мы оказались в такой ситуации. К сожалению, много придётся оставить за кадром... так что - спрашивайте!
Сергей Смирнов (Altair Engineering Inc.) | Организация работы распределенной ...RIF-Technology
В рамках доклада рассмотрим вопросы формирования команды с помощью модели МакКинси 7с (McKinsey 7s), поговорим о процессах разработки программного продукта, системе релизов, системном инжиниринге и рекомендациях по системе управления процессами.
Выступление будет интересно руководителям команд разработчиков, особенно тем, кто фокусируется на предсказуемости сроков и качестве создаваемого решения.
"Этот код плохой, его нужно переписать". Слышали? Как обосноватьMaksym Bezuglyi
Как на языке бизнеса доказать необходимость переписывания кода. Как бизнес может объяснить инженерам, что этого делать не нужно, либо как сделать это правильно с перспективы бизнеса.
В презентации:
• Что такое Концепция требований, для чего она нужна и что туда должно войти?
• Какие техники сбора и анализа требований можно использовать на старте проекта?
• Как можно формировать ТЗ к такому проекту и что туда должно войти?
• Какие моменты нужны учесть и какие инструменты можно использовать при управлении требований?
* Показаны и рассказаны реальные примеры докладчика.
Александр Сербул. Прикладное XP в «1С-Битрикс»: как развивать продукт более 1...ScrumTrek
В компании «1С-Битрикс более 10 лет успешно используется плеяда Agile методологий как для управления продуктом, так и для развития технологической платформы: от XP до Model Storming и Story Mappings, от глубокого проникновения всех «бойцов» общими командными целями и интенсивных визуальных коммуникаций без ТЗ, до выполнения топ-менеджерами компании интегрирующих ролей Scrum Master/ProductOwner, вплоть до парного программирования с генеральным директором. Самобытное и глубокое проникновение в культуру команды принципов Agile Manifesto, уважение клиента, возведенное в культ, с искренним желанием решить его технологические задачи, практическое стремление к техническому совершенству. Мы расскажем об этом, поделимся собственным опытом и инструментами, расскажем что работает лучше и когда, а что не взлетает ни при каких условиях. Особое внимание уделим особенностям применения Agile к задачам, требующим глубокого системного анализа и проектирования.
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...RIF-Technology
Самый большой проект, с котором сталкивалась наша команда занял у нас порядка 70 человеко-месяцев, к концу в проекте было около 9000 тикетов, объединённых в 318 эпиков. Объём технического задания превышал 1000 страниц. Как мы справились с этим довольно небольшой командой? Один менеджер, один аналитик, несколько разработчиков.
Нам помогли бизнес-процессы или попросту жёстко прописанные workflow для любой ситуации, любого вида задач или входных данных. Как задача обрабатывается аналитиком, когда она попадает программистам, когда пишется технический дизайн. Как эта схема накладывается на тикетную систему, как использовать эпики и задачи. Все эти правила мы выписали болью ошибок в планировании (и финансах) и я уверен, что они могут сэкономить вам несколько месяцев собственных опытов.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
Методы разработки качественного и чистого кодаIvan Novikov
Доклад на третьем митапе сообщества http://tver.io о том, почему не может существовать TDD в классическом виде, какие возможности преподносят нам использование суррогатных объектов и как отнестись к подходу скептично и использовать лучшие практики, которые метод разработки через тестирование привнес в инженерию ПО.
Доклад на hotcode.org о инструментах и методиках которые помогают нам повышать и следить за качеством PHP кода.
Среди затронутых тем:
- Стандарты в коде
- Средства для статического анализа кода.
- Git хуки
- Непрерывная интеграция
- IDE
- Code review
Как учиться в вузе, заниматься предпринимательством и не умереть в процессеMIkhail Neverov
Данная презентация использовалась для сопровождения лекции для русской группы Высшей IT-школы ТГУ.
Какие цели я преследовал в рамках своей презентации:
Рассказать про то, как можно отучиться в ТГУ, попробовать себя в бизнесе и не умереть в процессе
Приоткрыть завесу в разные аспекты профессиональной деятельности в сфере компьютерных наук
Рассказать как выглядит (и может выглядеть) современный IT-бизнес с моей точки зрения
Какие навыки нужны программисту, а какие - предпринимателю
Семён Факторович (Noveo) рассказывает о карьерных лестницах и различных профессиях в IT-индустрии, 20.02.2013
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
Проектирование интерфейсов. Декорации и архитектураAny Void
«Зачем нужны декорации, когда есть архитектура?»
Слайды выступления Юрия Подорожного на MDDay 2013. http://2013.mdday.ru/programm_fest/proektirovanie-mobilnyih-prilozheniy/
Оцінка проектів на етапі продажу. Практичні рекомендації та поради.Stfalcon Meetups
C'n'C #29 - IT Project Management
Ігор Федун
- Project Manager в Stfalcon.com
- У минулому Project Manager в Four-eyes.io
- Знаходжу позитивні моменти в будь-якій ситуації. Люблю відпочинок з друзями на природі
григорьев андрей, юмисофт, основные ошибки ведения It проектов - от документа...New Business Idea
Основные ошибки ведения IT-проектов - от документации до коммуникаций.
* Сбор и формирование требований к продукту;
* выработка стратегии;
* начальное проектирование;
* документирование процесса;
* построение схемы ролей и коммуникаций;
* дизайн проекта;
* программирование;
* примеры из жизни.
Tech Talks @NSU: Рассказ о разных профессиях в IT-индустрии, или почему не вс...Tech Talks @NSU
http://techtalks.nsu.ru
20 февраля 2013. Рассказ о разных профессиях в IT-индустрии, или почему не все выпускники IT-специальностей пишут код (Семён Факторович, Noveo)
«Семен Факторович (Noveo, Новосибирск) рассказывает о разных профессиях в IT-индустрии и о вариантах карьерного роста IT-специалиста»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Методики управления развитием ис на базе 1сHelen Kopteva
Данная презентация была представлена в ходе вебинара "Методики управления развитием ИС на базе 1С. СППР как возможный инструмент поддержки данных методик". Ведущий - Олег Демиденко, руководитель отдела внедрения, руководитель проектов компания "Кодерлайн".
Доклад для потенциальных заказчиков digital-услуг базового уровня. Как выбрать оптимальный веб-продакшен/digital агентство. Для конференции "Прокачка Бизнеса".
Как проекту привлечь средства через краудплатформу - Катерина Трубе, CONSTARTiDealMachine
Чем краудинвестинг отличается от краудфандинга, как правильно позиционировать и упаковать проект при выходе на краудплатформу и какие еще краудмеханизмы стоит взять на вооружение.
2. ЦЕЛИ И ЗАДАЧИ АУТСОРСИНГА
Разгрузить своих сотрудников для более важных задач;
3. ЦЕЛИ И ЗАДАЧИ АУТСОРСИНГА
Разгрузить своих сотрудников для более важных задач;
Сделать работу в которой не хватает знаний и нет времени/возможности
растить экспертизу внутри;
4. ЦЕЛИ И ЗАДАЧИ АУТСОРСИНГА
Разгрузить своих сотрудников для более важных задач;
Сделать работу в которой не хватает знаний и нет времени/возможности
растить экспертизу внутри;
При внутренней оценке работы она оказалось очень дорогой.
14. 1. CODE&FIX
ХАРАКТЕРИСТИКИ ТАКОГО ПОДРЯДЧИКА
Подробный workflow;
Эффективная инфраструктура разработки;
Роль заказчика четко определена;
15. 1. CODE&FIX
ХАРАКТЕРИСТИКИ ТАКОГО ПОДРЯДЧИКА
Подробный workflow;
Эффективная инфраструктура разработки;
Роль заказчика четко определена;
Код тестируют тестировщики, а не сами разработчики;
16. 1. CODE&FIX
ХАРАКТЕРИСТИКИ ТАКОГО ПОДРЯДЧИКА
Подробный workflow;
Эффективная инфраструктура разработки;
Роль заказчика четко определена;
Код тестируют тестировщики, а не сами разработчики;
Автоматизация для повышения качества.
17. 1. CODE&FIX
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Участвовать во всех коммуникациях внутри команды подрядчика;
18. 1. CODE&FIX
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Участвовать во всех коммуникациях внутри команды подрядчика;
Вести «живую» документацию;
19. 1. CODE&FIX
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Участвовать во всех коммуникациях внутри команды подрядчика;
Вести «живую» документацию;
Все проектные артефакты должны также остаться у вас;
20. 1. CODE&FIX
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Участвовать во всех коммуникациях внутри команды подрядчика;
Вести «живую» документацию;
Все проектные артефакты должны также остаться у вас;
Все задачи должны иметь описание и они должны быть связаны с
комитами;
21. 1. CODE&FIX
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Участвовать во всех коммуникациях внутри команды подрядчика;
Вести «живую» документацию;
Все проектные артефакты должны также остаться у вас;
Все задачи должны иметь описание и они должны быть связаны с
комитами;
Отдельная ветка/заметка для накопления знаний от подрядчика.
23. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
КАКОГО ПОДРЯДЧИКА ИСКАТЬ И ЗАЧЕМ ОН ВАМ
НУЖЕН?
24. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
ХАРАКТЕРИСТИКИ ТАКОГО ПОДРЯДЧИКА
Работал по time&material и/или саппортил написанный не им проект;
25. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
Работал по time&material и/или саппортил написанный не им проект;
У команды есть менеджер/тим лид;
ХАРАКТЕРИСТИКИ ТАКОГО ПОДРЯДЧИКА
26. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
Работал по time&material и/или саппортил написанный не им проект;
У команды есть менеджер/тим лид;
Оценку проводят осторожно, задавая много вопросов, переписывая ваш
бриф «как надо»;
ХАРАКТЕРИСТИКИ ТАКОГО ПОДРЯДЧИКА
27. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
Работал по time&material и/или саппортил написанный не им проект;
У команды есть менеджер/тим лид;
Оценку проводят осторожно, задавая много вопросов, переписывая ваш
бриф «как надо»;
Вас познакомят с конкретными разработчиками;
ХАРАКТЕРИСТИКИ ТАКОГО ПОДРЯДЧИКА
28. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
Работал по time&material и/или саппортил написанный не им проект;
У команды есть менеджер/тим лид;
Оценку проводят осторожно, задавая много вопросов, переписывая ваш
бриф «как надо»;
Вас познакомят с конкретными разработчиками;
Анализирует, советуются, внедряет.
ХАРАКТЕРИСТИКИ ТАКОГО ПОДРЯДЧИКА
29. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Проектируйте сами;
30. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Проектируйте сами;
Узнать статус вы должны без помощи подрядчика;
31. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Проектируйте сами;
Узнать статус вы должны без помощи подрядчика;
Никаких прямых комитов для сильно связанного кода;
32. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Проектируйте сами;
Узнать статус вы должны без помощи подрядчика;
Никаких прямых комитов для сильно связанного кода;
Общая среда разработки;
33. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Проектируйте сами;
Узнать статус вы должны без помощи подрядчика;
Никаких прямых комитов для сильно связанного кода;
Общая среда разработки;
Общее владение документами;
34. 2. ВЫСОКИЙ УРОВЕНЬ ЗРЕЛОСТИ
ПРОЦЕССОВ
КАК С ТАКИМ ПОДРЯДЧИКОМ РАБОТАТЬ
Проектируйте сами;
Узнать статус вы должны без помощи подрядчика;
Никаких прямых комитов для сильно связанного кода;
Общая среда разработки;
Общее владение документами;
Вводите в проект подрядчика сами.
35. 3. НА ЧТО СТОИТ ОБРАЩАТЬ
ВНИМАНИЕ
Высокая/низкая оценка стоимости по сравнению с другими предложениями;
36. 3. НА ЧТО СТОИТ ОБРАЩАТЬ
ВНИМАНИЕ
Высокая/низкая оценка стоимости по сравнению с другими предложениями;
Подрядчик запросил размер бюджета на проект;
37. 3. НА ЧТО СТОИТ ОБРАЩАТЬ
ВНИМАНИЕ
Высокая/низкая оценка стоимости по сравнению с другими предложениями;
Подрядчик запросил размер бюджета на проект;
«Мы этого никогда не делали, но не вижу проблемы чтобы это сделать»;
38. 3. НА ЧТО СТОИТ ОБРАЩАТЬ
ВНИМАНИЕ
Высокая/низкая оценка стоимости по сравнению с другими предложениями;
Подрядчик запросил размер бюджета на проект;
«Мы этого никогда не делали, но не вижу проблемы чтобы это сделать»;
Есть сильные не развеянные сомнения — не начинайте;
39. 3. НА ЧТО СТОИТ ОБРАЩАТЬ
ВНИМАНИЕ
Высокая/низкая оценка стоимости по сравнению с другими предложениями;
Подрядчик запросил размер бюджета на проект;
«Мы этого никогда не делали, но не вижу проблемы чтобы это сделать»;
Есть сильные не развеянные сомнения — не начинайте;
Определите для себя непоколебимые принципы. При систематическом
нарушении — заканчивайте работу;
40. Высокая/низкая оценка стоимости по сравнению с другими предложениями;
Подрядчик запросил размер бюджета на проект;
«Мы этого никогда не делали, но не вижу проблемы чтобы это сделать»;
Есть сильные не развеянные сомнения — не начинайте;
Определите для себя непоколебимые принципы. При систематическом
нарушении — заканчивайте работу;
Вы — заказчик. Не забывайте об этом
3. НА ЧТО СТОИТ ОБРАЩАТЬ
ВНИМАНИЕ