Nedcentr.ru

НЕД Центр
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Как составить требования к сотрудникам функционал задачи качества

Как составить требования к сотрудникам функционал задачи качества

Введение

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

    • значительно снизить итоговую стоимость проекта;
    • улучшить качество продукта;
    • сохранить нервы всей команде.

Отношение к тестированию требований на проектах

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

1. Группа А: лучшие практики в деле

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

2. Группа Б: успеть все

Документация готовится и уточняется параллельно с разработкой продукта, что серьезно осложняет жизнь как разработчикам, так и тестировщикам. Требования согласовываются с заказчиком и изменяются практически ежедневно. Это приводит к тому, что разработчики постоянно (на моей практике – по несколько раз в неделю) переделывают уже имеющийся функционал, а тестировщики меняют тест-кейсы. В результате каждый из членов команды выполняет двойную или тройную работу, повышается загруженность аналитика, а продукт долгое время не может пройти этап приемочного тестирования, так как всегда находятся серьезные дефекты даже в основном функционале.

3. Группа В: все усилия на разработку

Если указаны требования трехлетней давности – ты счастливчик, даже если этот функционал менялся уже 3 раза; у команды есть хоть какое-то понимание, как должна работать система. Большую же часть требований, раскиданных по чатам, приходится долго и упорно их искать (при этом со временем и сообщения из чата теряются, особенно при использовании бесплатной версии Slack). Зачастую при нахождении очередного дефекта отсутствует понимание того, как на самом деле все должно работать, кто должен править, и дефект ли это вообще. В таком случае все спорные вопросы адресуются аналитику или и без того загруженному менеджеру проекта. Ответ может занимать от часа до недели. Соответственно, в случае любой спорной ситуации тестирование останавливается на неопределенный срок.

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

Параметры тестирования документации

1. Четкость и ясность

Начать тестирование требований можно с поверхностного осмотра документации. Это сложно назвать именно тестированием, но нередко уже на данном этапе выявляется немало недочетов. Начнем с обычного сценария. Вы начали читать требования, и уже с первых строк у Вас возникает масса вопросов к автору (например, «Каков ожидаемый результат после нажатия на эту кнопку?» или «Что будет, если я отменю заказ?»). Это плохо. После прочтения документации не должно быть вопросов. Совсем. Требования – это как свод законов для продукта, а законы не допускают двусмысленность, «воду» и неточности. Документация должна давать предельно ясную информацию о том, как должен работать каждый отдельный модуль и весь продукт в целом. К сожалению, после прочтения большинства требований остается целый ряд вопросов.

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

Дальнейшее («более глубокое») исследование требует гораздо больших временных затрат.

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

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

  • время нескольких членов команды потрачено впустую;
  • итоговая позиция кнопок не соответствует ожидаемому результату.
    • при наличии подобных сообщений в командном чате нужно убедиться, что обновленные требования задокументированы;
    • необходимо сравнить даты обновления Технического Задания и Пояснительной Записки с датой последнего обновления требований.
Читать еще:  При разъездном характере работы как учитываются рабочие часы?

3. Логика
Как следует из названия, работа системы должна быть логичной. Пользователь не может изменить настройки своего профиля или написать письмо до того, как пройдет авторизацию в системе. Звучит, опять же, элементарно, но в проектах с множеством клиентов или со сложной логикой подобные ошибки часто допускаются.

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

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

4. Возможные сценарии
В документации должны быть подробно описаны как очевидные, так и неочевидные варианты использования системы. К очевидным (позитивным) вариантам, например, можно отнести ввод корректной пары логин/пароль. К неочевидным (негативным) – ввод некорректной пары логин/ пароль или отсутствие этих данных вовсе.

Пример. Часто из виду упускаются такие моменты, как тексты ошибок, поведение системы при потере связи, а также обработка ошибок, связанных со сторонними сервисами (например, с оплатой).

  • при потере связи система ведет себя некорректно (отсутствие ошибок, зависание);
  • сообщения об ошибках не очевидны;
  • в худшем случае возможны репутационные или финансовые потери.
    • нарисовать блок-схему отдельного модуля системы, в рамках которой обозначить все возможные
    • условия и действия пользователя;
    • убедиться, что в требованиях есть описание каждого возможного случая.

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

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

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

Основные принципы тестирования требований

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

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

Развитие стандартизации началось еще в Древнем Риме и коснулось единиц измерения, размеров, форм, строительных норм и правил. Собственная система качества существовала в Древнем Китае, в Индии и в Древней Руси, и все они зависели от индивидуального ремесленного мастерства.

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

Читать еще:  Соцзащита г Иркутск официальный сайт адреса телефоны график работы

Project manager: задачи

Обязанности проджект менеджера можно кратко описать так: он связывает заказчика и команду при работе над проектом . Таким образом, есть три основных звена, каждое из которых требует от PM-а внимания и активных действий. Давайте рассмотрим обязанности менеджера по проектам в каждой из трех сфер.

Заказчик

Прежде всего project manager должен разобраться в требованиях клиента к финальному продукту. На этом этапе PM расставляет приоритеты: какие функции приложения или сайта самые важные, как заказчик хочет удерживать клиентов, какие интересные решения конкурентов можно использовать.

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

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

Без менеджера проекта заказчику придется общаться с разработчиком напрямую. Те часы, которые программист мог потратить на код, он тратит на разговоры. Релиз приложения отдаляется, заказчик нервничает и теряет доверие. С PM каждый занят своим делом и не отвлекается на посторонние задачи.

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

Необходимые качества:

  • ответственность;
  • стрессоустойчивость;
  • навыки в сфере управления ;
  • умение вести переговоры.

Команда

Если проект небольшой и задействует только одного разработчика, заказчик теоретически сможет общаться с командой сам. Но если проект сложный, а в команде 5 человек — аналитик , дизайнер , тестировщик , фронт- и бэкендщик ? Клиенту придется созваниваться с каждым, ставить задачи, разбираться, чем фронт отличается от бэка, а React — от Angular. Он будет тратить на это рабочий день, вместо того, чтобы развивать бизнес и зарабатывать деньги. Таким образом, первостепенная задача менеджера проектов — управлять командой . В первую очередь необходимо отобрать нужных людей, а когда команда собрана, PM вводит коллег в курс дела и распределяет между ними обязанности и этапы разработки.

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

Без навыков управления руководитель проекта не сможет повлиять на действия сотрудников. Чтобы работа над проектом была продуктивной и приятной, PM мотивирует коллектив. Он может выстроить по-настоящему эффективное взаимодействие, чтобы работа была максимально комфортной. Хорошие проджект менеджеры предотвращают большинство конфликтов и без проблем справляются с возникающими.

Необходимые качества:

  • лидерские качества;
  • коммуникабельность;
  • навыки управления проектами ;
  • умение работать с людьми;
  • четкое и ясное изложение мыслей.

Проект

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

  1. Инициация — утверждение концепции и запуск проекта.
  2. Планирование — определение последовательности действий и подготовка к работе.
  3. Исполнение — работа над проектом по выработанному плану.
  4. Контроль — регулярный мониторинг каждого этапа, управление рисками и ведение отчетности.
  5. Закрытие — завершение проекта и передача документации заказчику.

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

На всех этапах РМ следит за качеством продукта и организует процессы разработки так, чтобы билды (сборки кода) тестировались как можно чаще. Это помогает ловить баги в самом начале проекта, а не перед релизом. Проектный менеджер проверяет, соответствует ли программное решение техническим требованиям и инициирует код ревью. Если необходимо, просит дизайнера верифицировать дизайн — выполнить авторский надзор, как это было на нашем проекте для курьерской службы СДЭК . Все эти действия обеспечивают качество финального продукта.

Читать еще:  Как составляется график отпусков и образец его заполнения

Необходимые качества:

  • уверенность в результате работы;
  • аналитические способности;
  • личная организованность;
  • высокая работоспособность.
  • знания в сфере IT ;
  • умение увидеть всю картину в целом.

Подходы к оценке работы персонала

Все существующие подходы анализа работы персонала разделяют на три большие группы.

Качественные и описательные методы – характеристика сотрудников без использования количественных данных. Качественная оценка включает:

— матричный метод: сравнение личных качеств сотрудника с идеальной моделью для анализируемой должности;

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

— анализ выполнения задач: общая оценка работы сотрудника;

— методика «360 градусов»: суммарная оценка сотрудника администрацией, клиентами, коллегами, подчиненными плюс самооценка;

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

Количественные методы – оценка сотрудников, базирующаяся на цифровых данных. Считаются самыми объективными и достоверными:

— метод балльной оценки: присвоение баллов за каждое достижение. Суммирование баллов по истечении временного периода (месяца, квартала и т. д.);

— ранговый метод: составление рейтингов сотрудников, сверяемых между собой для выявления лиц, занимающих самые низкие позиции;

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

Комбинированные методы – одновременное использование описательных и количественных параметров оценки. Считаются самыми эффективными:

— метод суммы оценок: анализ характеристик сотрудника по стандартной шкале и выведение среднего показателя, который сравнивается с оптимальным значением для конкретной должности;

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

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

Должностные обязанности бухгалтера по заработной плате

Должностная инструкция (ДИ) бухгалтера по зарплате должна подробно описывать все обязанности работника. Такой документ позволяет избежать спорных моментов и регламентирует взаимоотношения между специалистом и работодателем.

В обязанности бухгалтера необходимо включить контроль первичной документации, используемой при расчете зарплаты, отражение этих операций на счетах бухучета. Сотрудник должен готовить справки по форме 2-НДФЛ, рассчитывать социальные взносы, формировать отчетность. Будет нелишним обязать сотрудника повышать свои знания трудового законодательства в области начисления и выплаты пособий, предоставлении льгот отдельным категориям работников.

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

Методы разработки матрицы компетенций

Выделяют 3 основных способа разработки матрицы компетенций.

Заимствование готовой матрицы

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

Готовые решения под бизнес

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

Самостоятельная разработка

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

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

Важность HR-директора для компании

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

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

Директор HR – руководитель высшего звена, от него зависит не только работа HR-отдела, но и во многом всей компании. Это место должен занимать только высокоорганизованный человек, способный отвечать сразу за десятки процессов.

голоса
Рейтинг статьи
Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector