5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
технологии внедрения корпоративного портала с практическими примерами внедренийTatjana Ostretsova
В данной презентации мы собрали практический материал о том как правильно запустить коропоративный портал Битрикс24 в организации, стоит ли и когда привлекать подрядчика, рассмотрены некоторые технологии внедрения Битрикс24 Корпоративный портал, а также инструменты используемые на внедрении.
Интерфейс — Совместная работа аналитика и проектировщикаYury Solonitsyn
Краткий рассказ про то, как аналитик и проектировщик могут построить совместную работу над пользовательским интерфейсом, чем это полезно для них и для создаваемого продукта.
ITGM#8 Анна Абрамова Юрий Солоницын Интерфейс - совместная работа аналитика и...SPbCoA
Совместный доклад представителей двух сообществ: аналитиков и проектировщиков интерфейсов на ITGM#8.
Анна Абрамова (СПб СоА) и Юрий Солоницын (UXSpb) рассказали, как строится совместная работа аналитика и проектировщика интерфейсов в больших проектах. Где они помогают друг-другу и где начинают "толкаться локтями".
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...Ontico
РИТ++ 2017, Web-scale IT Сonference
Зал Владивосток, 6 июня, 17:00
Тезисы:
http://webscaleconf.ru/2017/abstracts/2553.html
Платформа виртуализации данных на основе Tarantool - система, созданная в Mail.Ru Group в прошлом году. Cовместно с АТ Consulting было создано и запущено в production решение для хранения 100 млн. профилей абонентов компании Beeline, выдерживающее значительные нагрузки.
...
Что DevOps должен знать про статический анализ кода?Andrey Karpov
Причины неудач внедрений.
Место статического анализа в DevOps-процессе.
Статический анализ – друг или враг.
Рассылка результатов анализа.
Что делать с 10 000 сообщений от анализатора при первом запуске?
Сколько времени нужно для правки всех ошибок?
Q&A, или что дальше?
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
Андрей Солоной "Как людям бизнеса работать с программистами"Startup_Technologies
Эксперт Startup Weekend, ведущий .NETразработчик и архитектор с большим опытом, ментор в EffectiveSoft Андрей Солоной выступил на Стартап-школе с мастер-классом: "Как людям бизнеса работать с программистами"
Осознанное развитие бизнеса в интернете. Что нужно ЗНАТЬ, чтобы не ошибиться ...borovoystudio
Осознанное развитие бизнеса в интернете. Что нужно ЗНАТЬ, чтобы не ошибиться там, где ошибается 95% проектов
Виталий Денисенков, директор Студии Борового
Семён Факторович (Noveo) рассказывает о карьерных лестницах и различных профессиях в IT-индустрии, 20.02.2013
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
Доклад для потенциальных заказчиков digital-услуг базового уровня. Как выбрать оптимальный веб-продакшен/digital агентство. Для конференции "Прокачка Бизнеса".
This document discusses continuous performance testing (CPT) and introduces the Jagger CPT solution. It provides an overview of why performance testing is important, outlines the principles and goals of CPT, and describes the key parts of the Jagger CPT platform including load generation, metrics collection, test data management, and environment management. It also provides an example customer success story where Jagger was used for continuous performance testing of a large ecommerce site.
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииSQALab
This document provides an overview of the JDI (Java UI test automation framework). It discusses features of JDI including being UI element oriented, providing common UI elements and solutions to common problems. It provides examples of how to write tests using JDI annotations and page object pattern. The document also summarizes benefits of JDI such as reducing test code, improving test clarity, reuse across projects. Finally it outlines new features planned for JDI 2.0 including layout verification, page object generator, integration with Selenium and expanding JDI to other languages like Python.
The document discusses testing of geolocation systems. It provides an overview of geolocation, including definitions and importance. It then outlines the speaker's experience and work testing GIS systems. The rest of the document details approaches to testing geolocation, including simulating calls, checking responses and databases, and verifying accuracy. It also discusses common data formats, projections, tools like PostGIS and QGIS, and potential bugs to watch for like coordinate jumbling. The conclusion emphasizes starting simple, practicing to improve, and for tests to grow with knowledge as geolocation is important for future IT.
5. Немного статистики
Вопрос: Ставит интересы заказчика
превыше всего
Вопрос: Всегда получает только
положительные отзывы от заказчика
0
10
20
30
40
50
60
70
80
Аналитик РП Разработчик ТП
>7 баллов, %
>7 баллов
0
10
20
30
40
50
60
Аналитик <7 б Аналитик >7б
Всегда получает
положительные отзывы
Положительные отзывы
6. Всех хороших аналитиков любят
заказчики. Кошмар начинается, когда…
Аналитик воюет с командой. В итоге аналитика любят, а
команду и компанию – нет.
Аналитик формирует требования, забивая забывая цели и
границы проекта.
Аналитик преследует цель удовлетворения в первую
очередь конечных пользователей.
Аналитик «сливается» с командой заказчика и не
отождествляет себя со своей командой. «Виноваты
разработчики».
10. Искаженное восприятие
проекта, границ и заказчика
Неадекватная самооценка
аналитика
Внешний локус контроля
Сдача границ проекта
Сдача личных границ
Защита границ заказчика
Капитуляция
Откуда растут ноги
11. Определение границ проекта
• Каковы цели и задачи проекта и каким образом их собираются
осуществить в рамках соответствующих ресурсных и временных
ограничений?
• Кто является заинтересованными сторонами и каковы их потребности
в проекте?
• Каковы возможности проекта и угрозы для его успешной реализации?
MOSCOW (Must have, Should have, Could have, Won’t have for now)
13. Как выглядят плохие границы
«Границы проекта должны включать в себя все
накладные, командировочные и т.д. расходы.
Подробные требования к системе должны быть
выявлены на этапе аналитики.»
14. Пример:
• Часть работ будет выполняться
удаленно, в офисе Исполнителя. Для
этого Заказчиком будет обеспечен
удаленный доступ к необходимым
информационным ресурсам.
• В рамках проекта реализации
Системы заложены две командировки
двух специалистов Исполнителя.
Расставляем границы правильно
Пример:
• Предполагается, что Заказчик предоставит
Исполнителю переводы названий
реквизитов, текстов оповещений,
комментариев и других элементов
интерфейса на украинский язык.
• Дополнительное брендирование Системы
кроме применение логотипов в рамках
проекта не предполагается.
• Предполагается поддержка системой
браузеров Internet Explorer 9 и выше,
Google Chrome 45 и выше.
15. Пример:
• Предполагается, что обеспечение
сервиса коротких сообщений будет
обеспечиваться интеграцией с MS
Lync (Skype for Business)
Расставляем границы правильно
Пример:
• Предполагается, что в рамках проекта
возможность формирования
документов на основании хранимых
шаблонов с заполнением параметров
будет реализована:
• не более чем для 5 шаблонов
для каждого модуля.
• Не более чем для 15 реквизитов
карточки, автоматически
заполняемых для каждого вида
шаблона.
16. Пример:
• Предполагается, что заказчик будет
использовать единый каталог
пользователей (Active Directory) для
всех подразделений.
Расставляем границы правильно
Пример:
• Техническая поддержка на этапах
опытной эксплуатации
осуществляется командой разработки
18. Магический круг проекта
Содержание проекта
Критерии приемки
результата
Границы проекта (что
входит в проект и что нет)
Ограничения проекта
Допущения проекта
20. 1 Выстроенный процесс управления изменениями
2
Участие аналитика в пресейлах и в предпроектной
активности
3
Прозрачная финансовая мотивация аналитиков в
привязке к прибыльности проекта
4
Качественная проработка границ проекта.
Изначальное понимание, насколько
открыты/закрыты границы
5
Сохранение сработанной команды из проекта в
проект
6 Изменение границ в обмен на что-то
7 Своевременная эскалация конфликтов и проблем
22. • Стараться понравиться всем
• Казаться лучше, чем есть
• Присваивать чужие
полномочия
• Бояться говорить «Нет»
• Оправдываться
• Вкладываться больше, чем
нужно
• Бояться субординации, если
она правильная
• Забывать про локус контроля
Стокгольмский синдром — термин популярной психологии, описывающий защитно-бессознательную травматическую связь, взаимную или одностороннюю симпатию, возникающую между жертвой и агрессором в процессе захвата, похищения или применения насилия. Под воздействием сильного шока заложники начинают сочувствовать своим захватчикам, оправдывать их действия, и в конечном счёте отождествлять себя с ними, перенимая их идеи и считая свою жертву необходимой для достижения «общей» цели.
В сфере ИТ данный термин прочно закрепился в адрес людей, постоянно контактирующих с заказчиком и склонных в любой момент «переметнуться» на сторону заказчика.
Чаще всего этот термин используют руководители проектов и менеджеры.
Если обратиться к статистике, то картина получается очень интересная. На последней оценке компетенций мы добавили 1 вопрос, который оценивал бы как раз склонность к стокгольмскому синдрому у различных специалистов.
Вопрос звучал следующим образом: Ставит интересы заказчика превыше всего. Респондентам предлагалось поставить балл от 1 до 10. Чем выше балл, тем больше сила утверждения фразы. 1 – соответственно, не ставит интересы заказчика ни во что =) Мы специально сделали немного коварную и размытую формулировку. Но результат оказался ожидаем. Почти 70 % аналитиков компании набрали >7 баллов. Ожидаемо, руководители проектов всего в 12 % случаев ставят интересы заказчика превыше всего. Но у большинства средний балл крутился около 5ки – то есть умеренно высокий: считаются с интересами заказчика, но во главу угла ставят интересы проекта и своей команды. Заметьте, что довольно высок % у специалистов технической поддержки. Действительно, аналитики наиболее склонны к стокгольмскому синдрому.
Но давайте посмотрим на еще одну диаграмму. Респондентам предлагалось ответить на вопрос «Всегда получает только положительные отзывы от заказчика». По большому счету, перекос здесь небольшой, но как раз в пользу людей, которые ставят интересы заказчиков превыше всего. В силу малой выборки ( у нас порядка 20 аналитиков) довольно непросто сделать однозначные выводы. Но всё-таки эта статистика дает нам основания полагать, что наличие стокгольмского синдрома и эмпатии к заказчику играет скорее положительную роль на проекте.
Было бы неправильно не спросить их подробнее, что они считают стокгольмским синдромом и в чем его опасность для проекта и команды исполнителя/подрядчика.
Я задала соответствующий вопрос руководителям проектов нашей компании, а также просто друзьям, которые работают в управлении проектами.
Вот несколько мнений, которые я выбрала как наиболее интересные:
Наверное для меня самым главным является, когда я полностью могу доверять человеку, когда он, находясь у заказчика, является действительно аватаром нашей команды, бережёт ее нервы и время и отстаивает наши интересы, а не его личные интересы.
Стокгольмский синдром – это когда отправляешь своего аналитика к заказчику, а обратно получаешь копию их менеджера проекта, которая говорит и думает языком заказчика, забывая, что на нашей стороне тоже есть совокупность причин выстраивать работу именно так.
Если сказать двумя словами, то это сливание своих границ и слияние с границами, установленными заказчиком.
4. У аналитика не может быть стокгольмского синдрома. Так как нет обязательных условий для его появления – захват, удержание, насилие. Люди получают деньги за свой нелегкий труд. Другое дело, что даже получая зарплату, многие всё равно не осознают себя в той же лодке, что и заказчик. Отделяют себя. А от этого и получается ощущение противостояния.
Давайте вместе определим основные признаки «стокгольмского синдрома», которые именно опасны для проекта (вопрос к залу).
Дальше постепенно открываем нужные пункты или все вместе.
Проект начинается с идеи и возникает с целью удовлетворения потребностей человека. Идея состоит в том, чтобы сделать что-то, что кажется необходимым. Преобразование идеи в проект начинается с понимания природы потребности как движущей силы. Поэтому потребности являются основной движущей силой проекта. 3 фазы в определении потребностей:Появление потребностей — все заинтересованные стороны должны предупреждать и предвидеть потребности, реагируя на них проактивно;
Признание потребностей — осознание потребностей на основе сбора информации и обсуждения с ЗС. Главная задача на этом этапе – превращение возникающей потребности в цели, которые начнут определять результаты проекта;
Формулирование потребностей — прояснение понимания потребности с помощью более точного описания ее характерных особенностей. Формулировка того, что должно быть сделано, т.е. определение границ, формулировка проекта.
Когда перечень потребностей (требований) сформирован, модель анализа MOSCOW (Must have, Should have, Could have, Won’t have for now) может помочь разделить требования на обязательные (Must have’s) и желательные (Should have’s). О том, что будет и не будет включено в проект, менеджеру проекта (с подачи аналитика, если это делается на этапе анализа) необходимо достичь соглашения с ответственным руководителем проекта и с управляющим советом проекта.
Границы проекта обязательно фиксируются в уставе проекта.
Необходимо точно определить, что проектная команде делать не будет.
В примере границы, которые обычно любят расставлять именно заказчики. Такие границы обычно очень выгодны с точки зрения возможностей пропихнуть кучу неоговоренного ранее функционала. Если на этапе предпроектного и проектного анализа вы допустите такую фразу в ТЗ, а не сторгуете её на более выгодную для себя, вероятность провала проекта увеличивается в разы. Еще хуже, если вы сами внесете в ТЗ аналогичную фразу без необходимости. Лучше ничего не писать, чем написать такое. Ружье, которое рано или поздно выстрелит.
А теперь поговорим о том, какие правильно выделить границы проект (с примерами)
А теперь поговорим о том, какие правильно выделить границы проект (с примерами)
А теперь поговорим о том, какие правильно выделить границы проект (с примерами)
Давайте вместе определим основные признаки «стокгольмского синдрома», которые именно опасны для проекта (вопрос к залу).
Дальше постепенно открываем нужные пункты или все вместе.
Поговорим по каждому пункту отдельно. Огромное влияние на возникновение проблем с границами оказывает искаженное их восприятие. То есть когда аналитик плохо понимает, где они вообще находятся и кто несет ответственность за их сдвиг.
Обычно такая ситуация возникает при некомпетентном управлении проектом с фиксированной стоимостью или на проектах по принципу аутстаффинга. На самом деле со вторым подходом все проще, так как в этом случае слияние заказчика и аналитика несёт скорее пользу, чем вред. Совершенно другое дело – это проекты с фиксированной стоимостью, где границы должны быть закреплены максимально жестко.
Можно выделить магический круг проекта, внутри вероятность свалиться в стокгольмский синдром аналитику или всей команде становится минимальной.
Он включает в себя понимание следующий принципиальных показателей проекта:
Описание содержания проекта
Критерии приемки результата
Границы проекта (что входит в проект и что нет)
Ограничения проекта
Допущения проекта
Четкое понимание всей командой этих пунктов и работа внутри этого круга – огромный залог успешного проекта. Всегда требуйте Пма формализации этих пунктов и согласования их с заказчиком вплоть до отказа от участия в проекте при их отсутствии. И помните, что работа в ситуации полнейшей неопределенности – это очень мощный демотиватор , который выльется в гораздо большие проблемы, чем проект, который был сдан с большими трудозатратами.