Поиск работы вызывает неприятные тревожно-азартные ощущения и у вчерашнего студента, и у профессионала с годами опыта за плечами. Это не признак неуверенности в себе, это проблема всей отрасли поиска персонала: мы идём на собеседование и понимаем, что не всё может зависеть от профессионализма, что кому-то не понравятся наши софт-скиллы или внешний вид, кто-то упрется в вопрос о причинах ухода с предыдущего места. На Хабре может выйти 200 статей-обращений к HR-службами IT-компаний, где сами соискатели будут с пеной у рта рассказывать, как с ними (нами!) нужно разговаривать, как оценивать, но на первой встрече с будущим работодателем вам всё равно подсунут психологический тест, зададут странные вопросы и посмотрят на вас, как будто вы уже что-то нарушили и идёте в компанию, чтобы порушить устои и корпоративную культуру. Поэтому мы не будем рассказывать компаниям, в чём они не правы — мы расскажем вам, как с этим жить. 

Это первая часть нашего нового цикла «Работа не волк», который будет состоять из пяти частей, каждая из которых раскрывает важнейшие аспекты, связанные с трудоустройством. Как и в случае с циклом про образование, статьи будут субъективными, честными и основанными на обширной экспертизе. Вот что вас ждёт:

Часть 1. Поиск работы: источники, резюме, собеседование с HR
Часть 2. Устройство и адаптация: собеседуем с боссом, проходим испытательный срок с ветерком
Часть 3. Работа в роли новичка: рост в компании
Часть 4. Работа в роли опытного сотрудника: как не перегореть
Часть 5. Увольнение: я ухожу красиво

Я хочу поделиться с вами моим опытом по настройке системы регистрации и обработки заявок Atlassian JIRA, совместно с Atlassian Confluence в качестве системы тех. поддержки пользователей. Что пишут Atlassian по поводу этого можно почитать тут: http://confluence.atlassian.com/display/JIRA/JIRA+as+a+Support+System

Есть несколько концепций организации тех. поддержки. Первая из них – это настройка отдельного проекта для каждого клиента. Но эта концепция не рациональна в связи с тем, что сотрудники тех. поддержки не видят общей картины и при большом количестве клиентов возникает переизбыток проектов. Поэтому я расскажу вам о другой концепции – с одним проектом Service Desk для всех клиентов с настроенными областями видимости.

Об авторских тренингах на тему: «Обучение проектированию ПО» подробнее можно узнать на моем YouTube канале

IV ОПРЕДЕЛЯЕМ ЦЕЛИ, ПРОЕКТА

Цель не обязательно должна достигаться. Порой это просто направление двигаться дальше.
Брюс Ли.

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

Цель данной группы работ: определить основные задачи, которые ставят перед собой группы заинтересованных лиц, участвующих в проекте.

Пролог

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

В своей статье «О качестве требований в ИТ проектах, начистоту (с позиции команды разработки)», я попытался более конкретно подойти к решению этих проблем и рассказал на своем опыте, как можно преобразовать собранные требования для автоматизации в ИТ проекте так, чтобы максимально повысить результативность команды, воплощающую их в целевой продукт. Повысить именно за счет качественно сформулированных заданий на разработку продукта, покрывающую весь процесс.

Теперь я хочу рассказать, как можно качественно сформировать сами требования, ведя Заказчика от его «хотелок», к его счастливому и плодотворному сожительству с программным продуктом, его мечты.
Об авторских тренингах на тему: «Обучение проектированию ПО» подробнее можно узнать на моем YouTube канале

— Привет! Ну ты как, кто, где? — давно не виделись.
— Да я менеджер ИТ-проекта в большой компании.
— О, PRINCE, риски, экстремальное управление, финансы. Сложно!
— Да не. Так, ТЗ от клиента технарям и обратно таскаю за деньги. Фигня.

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


Типичный прожект менеджер, который не очень понимает, что такое управление проектами

VIII Определяем сущности предметной области

Все, что видим мы, — видимость только одна.
Далеко от поверхности мира до дна.
Полагай несущественным явное в мире,
Ибо тайная сущность вещей — не видна
Омар Хайям

Определив абстрактные хранилища продукта, мы получаем костяк для построения детальной модели данных. При проектировании структуры сущностей продукта, удобно использовать канонические диаграммы «Сущность-связь» (ERD), логическую диаграмму (Logic Diagram) или диаграмму классов (Class diagram).

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

Теория проектирования такого типа диаграмм детально изложена в литературе, описывающей работу с UML. Например, эта тема очень удачно представлена в [11]. Поэтому остановлюсь лишь на некоторых аспектах, интересных на мой взгляд,.

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

Итак, я просил ответить на вопрос какие книги из статьи вы читали?

Результаты опроса:

Название книги	Количество голосов	Процент
Том ДеМарко. Deadline. Роман об управлении проектами	247	54%
Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы	174	38%
Джоэл Спольски. Джоэл о программировании	165	36%
Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды	148	32%
Джейсон Фрайд, Дэвид Хайнемайер Хенссон. Rework. Бизнес без предрассудков	108	24%
Джеффри Янг и Уильям Саймон. iКона. Стив Джобс	94	21%
Том ДеМарко, Тимоти Листер. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения	70	15%
Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд	51	11%
Кармин Галло. iПрезентация. Уроки убеждения от лидера Apple Стива Джобса	48	11%
Патрик Ленсиони. Смерть от совещаний	21	5%
Патрик Ленсиони. Пять пороков команды. Притчи о лидерстве	19	4%
Патрик Ленсиони. Пять искушений руководителя: притчи о лидерстве	16	4%
Патрик Ленсиони. Три признака унылой работы. История со смыслом для менеджеров (и их подчиненных)	11	2%

А теперь еще один бонус — список книг по заданной тематике, которые прислали нам читатели:

Друзья, добрый день!

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

Предисловие: целью данной публикации ставится получение обратной связи и сбор критики по статье от ИТ-сообщества в преддверии её печати в периодическом издании. В статье будет представлено краткое описание, в хронологическом порядке, популярных методологий в области управления информационными проектами.

В 1958 году консалтинговая компания «Booz Allen Hamilton Inc.» совместно с центром разработки «Lockheed Martin Space Systems» и подразделением программных разработок специального проектного центра департамента ВМС США разрабатывают технику оценки и анализа программ (проектов) «Program Evaluation and Review Technique» под кодовым названием PERT — для проекта разработки системы вооружения подводных лодок «Polaris» [1] (баллистические ракеты).

PERT разрабатывался для экономии времени при управлении крупными проектами, в которых время является критическим показателем. Методология предполагает анализ отдельно взятых задач в ракурсе их влияния на завершение всего проекта, в частности, анализируется время на выполнения каждой задачи, в результате чего определяется минимально необходимое время на прохождение всех этапов. Данная техника может применятся в условиях неопределенности, когда неизвестны детали каждого этапа и точное время на их выполнение, более того, это событийно ориентированная техника применяемая к проектам, где время более важный фактор, чем стоимость.

Данная методология применялась при подготовке к зимним олимпийским играм 1968 года в Гренобле [2], она же была первая в своем роде, возрождающая подход «Научной организации труда» [3] впервые описанный Тейлором Фредериком Уинслоу в 1911 году, пытавшегося применить науку для инженерии процессов и управления.

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

Но на самом деле как раз сейчас можно говорить о ней серьёзно. На пике ажиотажа сложно было пробиться через вопли «ВЛОЖИСЬ В НАШЕ ICO ПОКА НЕ ПОЗДНО» к чему-то рассудительнее, и в соотношении «сигнал/шум» зашкаливала вторая составляющая. Зато теперь, когда шумиха схлынула и любители быстрой наживы переключились на что-то другое, стало можно поговорить нормально. И когда вопрос «во что вложить деньги» перестал затмевать всё остальное, стало проще затрагивать технические аспекты.

Риан Льюис (известная, например, небольшим сервисом CountMyCrypto) видит блокчейн-экосистему и с ракурса энтузиаста, и с ракурса технического специалиста: ей интересно и «что вообще происходит», и тестирование блокчейн-проектов. И мы решили задать ей вопросы сначала о первом, а затем перейти к второму.

Отдел обеспечения качества (QA) занимается поиском багов в ПО. Методы отличаются в разных компаниях, но обычно этим занимаются сотрудники, знакомые с программным обеспечением. Они используют его различными способами и пытаются найти баги, которые упустили разработчики.

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

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

Как возникла необходимость отойти от классической Каскадной Модели жизненного цикла разработки

В 2009 году мне предложили выбрать и реализовать один из «гиблых» проектов. Приставку «Гиблый» каждый получил за то, что раньше за них уже пробовали браться, но ничего не вышло.

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

Большой пример: только оказавшись под санкциями и цене нефти в 50 долларов за баррель (против 110 ранее) руководство страны перешло от рассуждений и неспешных телодвижений к активным действиям по развитию высокотехнологичной экономики.

Так и один из моих Заказчиков созрел и я взялся сделать для него проект по разработке нового функционального модуля Корпоративной Информационной Системы (ERP-системы), который должен был добавить 400 новых пользователей системе и обеспечить проверку 40 000 ипотечных кредитов в год.

Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.

Но зачастую меня внедряли в небольшие команды, в которых было от 5 разработчиков на 1-2 тестировщика и, как правило, большая жара в проекте. Собственно, о том, как научиться понимать, где вы очутились и как начинать продвигаться в постановке QA-процессов, я и хочу поделиться с вами.

Первым делом вам стоит понять, на каком вы проекте

Накопив опыт от участия в проектах, я бы условно разделил их на 3 вида:

• проекты без тестирования;
• проекты с недобросовестным тестированием;
• проекты с тестированием.

В прошлых частях

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

В прошлой, второй части я рассказал про частые проблемы предпроекта и получил в комментариях закономерные замечания: «Хорошо написано о проблемах, всё как в действительности. Но решение предлагается в стиле «Не делайте плохо, и будете делать хорошо» neskazhui, «Но это жизнь, она в целом в статье и написана. А как надо-то?» other_letter.


Рассказ о том, как надо, я разделю на части:

1. Как правильно: то есть хорошо бы так делать, но обычно это получается лишь частично. Это будут следующие два рассказа.
2. Какие можно дать советы по каждой фазе работы с требованиями: чтобы облегчить ситуацию, когда что-то пошло неправильно, чтобы вписаться в реальные ограничения.

Пробная версия этой статьи ранее уже публиковалась мною.

I Вступление

Я хочу поделиться теорией, которую недавно создал.
Агент Смит (Фильм «Матрица»)

Немного о себе. На заре своей карьеры я долгое время работал программистом. Позже, когда мне стало скучно просто кодировать, переквалифицировался в системного аналитика, попутно исполняя функции менеджера проектов. В последнее же время обстоятельства сложились так, что совместно с партнерами мы создали небольшую ИТ компанию.

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

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

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

В прошлых частях

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

Во второй части я рассказывал про частые проблемы предпроекта.

В прошлой заметке мы обсуждали первую часть базовых принципов:

• Устройство IT-системы и классификация IT-продуктов.
• Уровни V-модели и жизненный цикл системы.
• Взгляд на систему как на финансовый актив.

В этой заметке мы закончим с описанием «как правильно», чтобы дальше обсудить, что делать, если правильно не выходит.

О чём вы узнаете из этой заметки:

• О конусе неопределенности и фазах проектирования.
• О том, как работает оценка.
• О полном составе задач предпроектной фазы и реализуемых при этом ценностях.
• О том, как получить достаточное количество ресурсов на предпроект.

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

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

Что конкретно может повлиять на принятие решения о необходимости смены концепции мобильного приложения или даже внесении некоторых коррективов в существующий продукт?

Изучив и опробовав на практике несколько вариантов Agile-управления проектами, я десятки раз сталкивался с ситуациями, когда красивая теория не работает на практике. Люди просто не в состоянии предвидеть свое будущее и более-менее адекватно оценивать время и собственные силы, вне зависимости от того, на сколько этапов раздроблен проект и как красиво нарисованы все управляющие графики и таблицы. Когда нам в 35-й раз завернули дизайн — уже казалось, что ситуация просто безвыходная и спасти нас может только чудо.

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

Что такое технический долг? Можно ли понимать его, как плохое исполнение разработчиками своих обязанностей? Возможно ли избежать появления технического долга, и следует ли его избегать? Как связан технический долг с архитектурой приложения и с доверием между заказчиком и исполнителем? Какие стратегии применяются для контроля технического долга?

Предлагаю вашему вниманию перевод интервью, вышедшего в подкасте «Software Enginering Radio» в апреле 2015 года. Свен Йохан и Эберхард Вольф обсуждают внутреннее и внешнее качество ПО, вспоминают общепринятые модели качества и стратегии, направленные на поддержание внутреннего качества ПО. Технический долг, в основном, рассматривается в контексте управления программными проектами.