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


Когда рабочий софт не оставляет равнодушным

Корпоративная культура, которую мы не понимаем


Какие элементы корпоративной культуры вы знаете? Корпоративы, поездки на конференции, покупка книг и подписок на журналы, питание в офисе, удобный транспорт и т.д. Как правило, дело и в теории, и на практике ограничивается этим списком. Попробуем найти определение в профильных учебниках, например в учебнике «Организационная культура» авторства И.П.Беликовой. Читаем: «Организационная (корпоративная) культураэто система разделяемых трудовым коллективом ценностей, убеждений, верований, норм, традиций, которые определяют соответствующий стереотип поведения людей в сфере трудовой деятельности. Организационная культура выражает уровень социальной интегрированности и профессиональной зрелости трудового коллектива в процессе достижения целей организации Давайте не будем обсуждать это определение, ок? Его прочитать — уже труд. Давайте откинем все эти мысли про верования и традиции, а поговорим по-людски.

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

  • взаимодействие сотрудников — чаты, электронная почта, корпоративные мессенджеры, видеосвязь, телефония
  • бизнес-процессы — BPM-системы, CRM-системы
  • цели бизнеса — планировщики, групповые планировщики, системы управления проектами и задачами
  • система вознаграждения — автоматизированные матрицы и системы расчёта KPI
  • текущая работа — документы с совместным редактированием, SVN, багтрекеты, тикет-системы и проч.

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

  1. сегодня CRM-системы стали распространенным универсальным ПО, которое покрывает и автоматизирует большинство процессов в компании (уже давно не только продажи и маркетинг);
  2. мы разрабатываем CRM-систему RegionSoft CRM, внедряем её клиентам и, конечно, используем сами, поэтому как никто знаем, как в рамках одной системы работать всем — от программистов до продажников, и при этом работать продуктивно.

Культура и бескультурие использования ПО


Существует гипотеза, и не мы её придумали, что в современном мире организации могут формироваться программным обеспечением, которое они используют. Эта гипотеза пошла от известной теории Мела Конвея (Mel Convey) о влиянии организационной модели компании на разрабатываемый ею продукт.

В 1967 году канадский учёный Мел Конвей (Mel Convey) предложил теорию о том, что продукты, разработанные софтверными компаниями, впитывают и отражают организационную структуру корпорации. Его теория была подтверждена позже и другими исследователями. Действительно, если обратить внимание на продукты компаний и почитать практики управления в них, можно увидеть, что софт отличается. Например, сравните мощный, функциональный, но путаный и часто неоднозначный в разработке Android и строгий, выверенный, отрегулированный iOs. Так что в картинке ниже есть только доля шутки.

А как у вас?

Таким образом, можно предположить, что используемое ПО и организационная культура компании также могут быть связаны. Действительно, даже по выбору CRM-системы можно понять, как компания принимает себя внутри рынка: простые стартапы и небольшие креативные агентства выбирают облачные решения и не особо заботятся о клиентской базе и данных, а вот зрелые малые, средние и крупные компании предпочитают либо комбинацию облака и десктопа, либо чистое on-prem решение — так данные защищены надёжнее, а затраты на автоматизацию предсказуемы и нередко значительно меньше.

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

Основная деятельность


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

  • Все сотрудники должны быть проинформированы и вовлечены в процесс внедрения.
  • Должны быть учтены все значимые интересы сотрудников.
  • Все сотрудники должны быть обучены и иметь полные инструкции по использованию средств автоматизации.
  • Сотрудники должны использовать ПО в повседневной деятельности и получать результат.

Отчётность


Отчёты — важный корпоративный инструмент коммуникации между сотрудниками и руководителями, особенно в крупной компании. С одной стороны, отчёты нужны самим работникам для того, чтобы видеть объём решённых задач ежедневно/еженедельно/ежемесячно, а с другой — руководителю, чтобы получать адекватные и честные данные о положении дел в компании. Как делаются отчёты в некоторых компаниях (даже ИТ-шных)? В конце периода сотрудники сидят и заполняют таблички, которые выкладывают на шару, а руководитель там их смотрит (или нет). Самое удручающее — это когда просят указывать точное время выполнения задач. Так и хочется написать: «С 8 утра до 10 — подвиг. 16:00 — война с Англией». Смысла в таких отчётах нет.

Другое дело, когда отчёт формируется по заданным принципам, и информация в них ценная и практически применимая:

  • отчёт должен быть своевременным
  • отчёт должен быть точным
  • отчёт должен соответствовать поставленным задачам
  • отчёт должен содержать результат.

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

KPI


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

Эээ, может, нам нужно новое ПО для мотивации...

Как не надо делать.

  • Рассматривать KPI как средство устрашения и наказания. Компании включают в матрицы коэффициентов показатели, которые звучат как «лояльность компании», «уровень включённости в коллектив» и т.д. Сами понимаете, весьма обтекаемые формулировки, на которых всегда можно подрезать премию нелюбимому подчинённому.
  • Увязывать KPI с должностными обязанностями сотрудника. Это особенно часто бывает, когда в матрицу коэффициентов попадают не план-фактные показатели, а макрозадачи с «оценкой». В конце периода можно легко перераспределить веса в пользу наиболее плохо выполненных задач вне должностных обязанностей и снова снизить или обнулить премию.
  • Делать KPI способом распределения премии внутри кучки своих людей.
  • Насильно насаждать KPI там, где они не применимы. Нередко на Хабре разворачиваются дискуссии о том, что считать показателем программиста. Это один из проблемных вопросов. Для подобных случаев лучше оценивать задачи либо в укрупнённом периоде либо с меньшим весом по исчислимым показателям (закрытым багам, тикетам, заданиям и т.д.).
  • Скрывать структуру и динамику KPI от сотрудников.

Как надо делать.

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

Безопасность


Безопасность — важная часть культуры использования программного обеспечения в компании. Более того, уровень безопасности как раз определяется этой культурой. Увы, строить отношения с сотрудниками на одном доверии практически невозможно. Нужно защищать наиболее уязвимые стороны бизнеса и, прежде всего, клиентскую базу. Тот же программный код защищён патентом и является интеллектуальной собственностью компании, а вот данные клиентов защищены разве что бумажкой о коммерческой тайне, которую подписывает сотрудник при поступлении на работу. Иногда ни что-то отсудить, ни наказать недобросовестного работника не представляется возможным.

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


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

Выбирайте программное обеспечение, как сотрудника


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

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

В нём должно быть удобно работать — именно с точки зрения практических задач. Удобство корпоративного ПО — это совсем иное, чем удобство социальной сети или мессенджера. За юзабилити в рабочих программах отвечает прежде всего релевантность процессам. Например, CRM — идеальный инструмент для работы с клиентами в полном цикле. А значит, что на первом месте должны быть не красивенькие дашборды, а рабочий стол, карточка клиента и сквозная связанность сущностей (чтобы из любого места можно было создать любой объект). Дашборды тоже чудесно, конечно, но когда они засоряют рабочее место сотрудника, им грош цена.

ПО должно соответствовать требованиям сотрудников для их основной деятельности. Этот факт кажется очевидным, но, например, в издательстве одной из газет макеты верстались даже не в Corel Draw и даже не в MS Publisher, а в Word и Power Point, потом пережимались в PDF и ехали в печать. Самиздат XXI века :-) Поэтому стоит внимательнее относится к задачам, которые должно решать программное обеспечение. Кстати, разработки это тоже касается: багтрекер, IDE, тикет-система должны отвечать рабочим задачам, выбранным языкам программирования и модели управления разработкой. Например, в одной довольно большой и известной компании замена Jira на Bugzilla сократила время заведения багов втрое, а на «вырученное» время тестировщики перераспределили между собой тест-планы, занялись написанием скриптов для автоматических тестов и выиграли ещё время для новых тестов. Хотя где-то может произойти и противоположный эффект.

Софт должен вписываться в общие процессы компании и соответствовать стилю руководства. Ну вот представьте себе гипотетически: небольшое рекламное агентство выигрывает приз рекламного фестиваля, на него валятся заказы, клиентов и денег стало много, нужна CRM. И вот оно решает, что победителю фестиваля к лицу только SAP и ничто иное. В итоге небольшая, талантливая, креативная и толковая команда получает себе на ПК концентрат бюрократии, сложности и перегруженности в данной ситуации. Инвестиция в дорогое ПО просто не окупается — им никто не пользуется. Соответственно, перед внедрением стоит провести ревизию процессов, проинспектировать организационную структуру, желаемую отчётность и т.д. и уже после этого выбирать и внедрять ПО.

Всё ПО внутри компании должно быть именно рабочим, а не вовлекать сотрудников в непрерывное общение. Хотя цифровая эмпатия (виртуальное общение работников с перенесением оффлайновых практик) определённо должна быть. Если система (CRM, мессенджер, корпоративный портал, почтовый клиент, ВКС и т.д.) превращаются в инструмент весёлого времяпрепровождения в офисе, это чревато прокрастинацией и срывами сроков. Именно поэтому мы всегда призываем с осторожностью относиться к так называемым корпоративным социальным сетям и любой геймификации. В конце концов, пусть лучше будет потрачено лишних 15 минут на болтовню за чаем, чем часы на обсуждение скидок в интернет-магазине в чате.

Я не прокрастинатор, я просто необычайно продуктивен в не самых важных задачах

ПО не может решить все проблемы. Компании ставят программное обеспечение и ждут от него чуда (самостоятельной работы): BI должна сама анализировать, CRM сама продавать, система управления проектами — заглядывать в диаграмму Гантта и тыкать сотрудников в спины за полчаса до дедлайна. А иногда чудес никто не ждёт, а просто неправильно понимают, о чём софт. Вот вам свежий пример того, как о ПО рассуждает руководитель консалтинговой компании:

Не приводим издание, хотя и можно легко нагуглить

Что можно ожидать от такого понимания программного обеспечения? Ровным счётом ничего. С таким подходом любое внедрение потерпит фиаско. К сожалению, именно непонимание работы программного обеспечения приводит к ложным мыслям о его всемогуществе. Но это всего лишь инструмент, и эффективно он может работать только в руках специалиста. Поэтому первоочередная задача — «подружить» сотрудников и ПО, а потом уже требовать эффективности.

Программное обеспечение не должно насаждаться исключительно сверху и по материальным мотивам. Мнение сотрудников должно учитываться, они должны принимать участие в выборе и внедрении корпоративного ПО. В конце концов, работать в программах предстоит именно им, поэтому сотрудничество строго необходимо. Увы, в некоторых российских компаниях побороть насаждение сверху очень сложно именно потому, что менеджеры высшего звена почти что кровно заинтересованы в материальных аспектах внедрения. Говоря простым языком, либо имеют откат, либо получают бонусы тем выше, чем сложнее и дольше длится проект. Поскольку снизу эту тенденцию не побороть, забота о грамотном управлении автоматизацией должна лежать на генеральном директоре. Он-то кровно заинтересован в быстром старте, эффективной работе и росте выручки. И он же должен инициировать создание рабочих групп. Конечно, такая ситуация не во всех компаниях, и это очень радует.

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

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

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

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

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



Кстати, мы ищем партнёров в регионах РФ и СНГ — пишите, звоните, особенно, если вы умеете и желаете работать и зарабатывать. Приветствуются компании и ИП, готовые писать отчёты, скрипты, обучать пользователей и забирать весь доход от этого себе, а с нами делить только стоимость лицензий.

Комментарии (19)


  1. Cerium
    16.01.2018 19:35
    +4

    Конечно, это всё классно и чётко. Но вот вам ситуация. Автосалон, точнее, дилерский центр известной «народной» марки. В партнёрстве с одной компанией стоит замечательный софт на машинках для отслеживания сроков ТО и т.д., должно всё быть по фен-шую: срок подходит ---> у водителя СМС «пройдите ТО со скидкой N%»----> контрольный звонок в голову ----> ТО пройдено, салон с выручкой, мы при процентах с продаж. Ноооооо!

    1. CRM не интегрирована с этим софтом и нам совершенно непонятно, пришла ли СМС тому, кому нужно звонить.
    2. У каждого менеджера свои крысиные записулечки с левыми клиентами — считайте, минус у нас всех остальных.
    3. Работоспособность софта на машинках никак не отчекать.
    4. Админ — приходящий парень из разряда «приди, когда у босса нет интернета».

    Конечно, мы живём и выживаем, ибо автомобилей этой марки много, а центров не так много. Но вот оно, полное, тотальное, темнущее ИТ-бескультурие. Как с этим бороться — ХЗ.

    Если что, я не ИТ-шник, я инженер, но, конечно, крепко в теме, как без этого.


    1. Subrisk
      16.01.2018 20:56

      Жесть, но она всюду есть. Можно уйти, можно попробовать бороться (нет, я не верю в то, что говорю). Культура ПО в компании зависит от культуры её руководителя. Он сам должен выступать драйвером — не только внедрения, как в посте написали, но и использования. Вот вам примеры:

      1. Та же самая CRM. Руководитель не использует её, задачи ставит лично, в чате или почте, отчёты по Экселькам собирает. Так какая мотивация у сотрудников пользоваться системой? Минимальная.
      2. Руководитель экономит на автоматизации и сотрудники имеют устаревший софт, клиентскую базу держат в файликах. Так что потом на утечку данных жаловаться?
      3. Руководство относится к софту попустительски: можно ставить нелицензионное ПО, кряки и прочие непотребные вещи. Компания рано или поздно нарывается на штрафы и административные дела. От этого хуже всем, но история повторяется вновь и вновь.

      Моя позиция такая: если руководителю наплевать на софт, ему наплевать на сотрудников и бизнес. В ответ он получит ровно такое же отношение. Ваша история, n'est-ce pas?


      1. Barafu
        16.01.2018 23:32

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


  1. AllanStark
    16.01.2018 20:48
    +1

    Не флейма ради…
    По-нормальному верстают в издательских системах / системах для верстки.
    Это Adobe InDesign и Quark XPress. CorelDraw — векторный редактор, хотя и с примитивными возможностями многоколоночной верстки в виде текстовых фреймов и TextFlow между ними.
    Все это достаточно дорогие пакеты, так что MS Publisher для какой-нибудь газеты для города в 50-100 тыс. населения — самое то. Это если не хочется попробовать вполне удобный бесплатный Scribus, который делался под влиянием старых версий Quark XPress.
    А так — извратов видел немало, даже сверстанную в MS Excel газету из какого-то села…
    И графический «макет рекламы» (несколько стандартных цветных геометрических фигур и объемная надпись фирмы-заказчика) в Discreet 3DS Max приносили…


    1. RegionSoft
      16.01.2018 21:01

      Отличный ликбез! Спасибо за информацию. Конечно, речь шла не о небольшом тираже — газета для города-миллионника с большим тиражом. Поэтому и ситуация трагикомичная. Одно утешает — история ушла в уже далёкие 2000-е :-)


  1. Mur466
    16.01.2018 21:02

    А можно поподробнее раскрыть тему замены jira на bugzilla и многократного ускорения заведения тикетов? За счет чего?


    1. RegionSoft
      16.01.2018 21:35
      +1

      История нашего сотрудника, который ранее работал в той компании. Цитируем прямо дословно:

      «Дано: 4 продукта в разработке, тест-планы по 200-300 пунктов на каждый. Был отдел тестирования А, 9 человек, работали с Jira как багтрекером, насоздавали полей и сущностей, которые не использовали. В течение года по многим причинам (в том числе из-за факапа с важным клиентом) сменили весь отдел — тогда появились мы, расширились до 12 человек. Насоздавали своих сущностей. Сменился начальник R&D. Через некоторое время вот что обнаружили:
      — сущностей стало слишком много, интерфейс потяжелел — затруднился поиск багов и событий
      — весь остальный стек был не атлассиановский
      — мы начали внедрять Scrum и „монстра“ мешала в процессе
      — самое ужасное — перегруженная система стала тормозить.

      Мы не хотели ничего менять, но кто-то вспомнил, что работал с Багзилой. Накатили перед одним релизом и полностью испробовали на нём: всем понравилась структура, все эти прозрачные вехи, милестоуны, статусы. Накатили ещё и Bugzilla TODOs, правда, не зашло. Довольно долго пользовались параллельно, что-то перетащили. В итоге работать стали реально в разы быстрее.

      Выводы? Отчасти хороший инструмент Jira загубили кучей настроек, которые хотелось применить, отчасти не подошла её философия. Миграция была сложной, если этот процесс вообще можно было назвать миграцией. Но ехать на помирающей лошади тоже не стоит, даже если ты её сам и загнал.»


      1. RationalBot
        17.01.2018 10:15

        мы начали внедрять Scrum и „монстра“ мешала в процессе

        Я, конечно, очень давно последний раз видел Bugzilla, но мне мне кажется очень сомнительной идея использовать ее при внедрения Скрама.
        Или там была какая-то кастомизация?
        Вот цитату нашел:

        Unlike some other tools, Bugzilla aims to be fairly generic. It was not built specifically for managing Scrum user stories, so it may take some work, frustration, and training to set it up appropriately. The writeup from the Songbird team hints at this — the first section is named «Wrestling Bugzilla into shape» and the next sentence explains that the team primarily chose Bugzilla for managing Scrum because they had already been using it.

        Уже неактуально?


        1. RegionSoft
          17.01.2018 10:24
          +1

          Ответ:

          «Как раз был 2012 год — и в марте Мозилла выпустила такой вот релиз. Решение было прямо скажем так себе. Потом появились ещё аддоны, но к тому времени мы решили, что со Scrum в чистом виде у нас не сложится :-) В итоге так и работали, что-то от скрама, что-то от водопадной модели.»


  1. StjarnornasFred
    16.01.2018 22:46

    Хотелось бы ещё раз обсудить тему KPI для программистов. Это ведь действительно проблема для бизнеса — вычислить количество полезной работы, которую произвёл программист. Деятельность творческая, иногда и «плевание в потолок» — важная часть рабочего процесса. Мои предположения таковы:
    1) Задача и время. Ставится цель и адекватные сроки для неё. Если программист или команда справились досрочно — молодцы, получают премию. При этом что и как происходит в процессе — не изучается, даже если разработчик еле протрезвел за полдня до дедлайна. Главное — в отведённый срок выполнить поставленную задачу.
    2) Комплексный KPI. Учитывать всё понемногу: и число строк кода, и вес кода, и потраченное время. В этом случае будет невозможно накрутить показатели путём построчной «маяковщины» или искусственного затягивания сроков, поскольку каждый показатель в отдельности имеет небольшой вес и не вызывает желания накручивать.


    1. andreylartsev
      17.01.2018 09:30

      Ни то ни другое разумеется не работает. Поэтому и появились эти ваши Аджайлы/Скрамы и Сторипойнты.


      1. RationalBot
        17.01.2018 12:19

        Появились Аджайлы и Скрамы, конечно же не поэтому, а потому, что традиционное проектное управление плохо подходит для проектов с высокой долей неопределенности. По сути, это ответ индустрии на ситуацию, когда 70% проваливались или не укладывались в бюджет.
        KPI гибким методологиям не противоречит. Например, есть такой KPI, как процент успешно выполненных спринтов (с точки зрения достижения целей).

        Сторипоинты — это альтернатива оценки трудоемкости задачи в человеко-часах. Прямой связи с KPI не вижу.


    1. Axelus Автор
      17.01.2018 10:44
      +2

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


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


      1. RationalBot
        17.01.2018 12:25

        Что значит «оценка в KPI»? KPI может быть несколько (или даже несколько десятков), т.к. целей у организации может быть несколько.
        Речь о пересчете показателей в компенсационный пакет?


        1. Axelus Автор
          17.01.2018 12:59

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


          1. RationalBot
            17.01.2018 13:50

            Вот так сразу целое направление Digital, когда человек исключается как промежуточное звено в продаже товаров или услуг, стало неактуальным?
            Скажем, для подсчета NPS (Net Promoter Score) можно вполне себе обойтись без людей — именно по этой причине опрос встраивают в сам интерфейс.
            Не так давно гремели «диванные войны» вокруг Кинопоиска, когда пользователям не понравились изменения. Оштрафовать всех разработчиков, приложивших руку?


    1. RationalBot
      17.01.2018 12:44

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

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

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


      1. Axelus Автор
        17.01.2018 13:04
        +1

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

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


        1. RationalBot
          17.01.2018 14:14

          Соглашусь, что я привел очень простую модель.

          Это же классическая воронка продаж.

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