Comments 19
Конечно, это всё классно и чётко. Но вот вам ситуация. Автосалон, точнее, дилерский центр известной «народной» марки. В партнёрстве с одной компанией стоит замечательный софт на машинках для отслеживания сроков ТО и т.д., должно всё быть по фен-шую: срок подходит ---> у водителя СМС «пройдите ТО со скидкой N%»----> контрольный звонок в голову ----> ТО пройдено, салон с выручкой, мы при процентах с продаж. Ноооооо!
1. CRM не интегрирована с этим софтом и нам совершенно непонятно, пришла ли СМС тому, кому нужно звонить.
2. У каждого менеджера свои крысиные записулечки с левыми клиентами — считайте, минус у нас всех остальных.
3. Работоспособность софта на машинках никак не отчекать.
4. Админ — приходящий парень из разряда «приди, когда у босса нет интернета».
Конечно, мы живём и выживаем, ибо автомобилей этой марки много, а центров не так много. Но вот оно, полное, тотальное, темнущее ИТ-бескультурие. Как с этим бороться — ХЗ.
Если что, я не ИТ-шник, я инженер, но, конечно, крепко в теме, как без этого.
1. CRM не интегрирована с этим софтом и нам совершенно непонятно, пришла ли СМС тому, кому нужно звонить.
2. У каждого менеджера свои крысиные записулечки с левыми клиентами — считайте, минус у нас всех остальных.
3. Работоспособность софта на машинках никак не отчекать.
4. Админ — приходящий парень из разряда «приди, когда у босса нет интернета».
Конечно, мы живём и выживаем, ибо автомобилей этой марки много, а центров не так много. Но вот оно, полное, тотальное, темнущее ИТ-бескультурие. Как с этим бороться — ХЗ.
Если что, я не ИТ-шник, я инженер, но, конечно, крепко в теме, как без этого.
Жесть, но она всюду есть. Можно уйти, можно попробовать бороться (нет, я не верю в то, что говорю). Культура ПО в компании зависит от культуры её руководителя. Он сам должен выступать драйвером — не только внедрения, как в посте написали, но и использования. Вот вам примеры:
Моя позиция такая: если руководителю наплевать на софт, ему наплевать на сотрудников и бизнес. В ответ он получит ровно такое же отношение. Ваша история, n'est-ce pas?
- Та же самая CRM. Руководитель не использует её, задачи ставит лично, в чате или почте, отчёты по Экселькам собирает. Так какая мотивация у сотрудников пользоваться системой? Минимальная.
- Руководитель экономит на автоматизации и сотрудники имеют устаревший софт, клиентскую базу держат в файликах. Так что потом на утечку данных жаловаться?
- Руководство относится к софту попустительски: можно ставить нелицензионное ПО, кряки и прочие непотребные вещи. Компания рано или поздно нарывается на штрафы и административные дела. От этого хуже всем, но история повторяется вновь и вновь.
Моя позиция такая: если руководителю наплевать на софт, ему наплевать на сотрудников и бизнес. В ответ он получит ровно такое же отношение. Ваша история, n'est-ce pas?
За ней следует вторая стадия: у всех урезанные учётки, интернет запрещён, флешки запрещены, везде стоят следящие программы. Вася хочет уйти в отпуск, Петя согласен доделать его отчёт, но чтобы передать отчёт Пете на комп, нужны разрешения админа, босса, начальника по безопасности и руководства ДНР. Всё это в фирме, обеспечивающей трёхногими табуретками Барнаул.
Не флейма ради…
По-нормальному верстают в издательских системах / системах для верстки.
Это Adobe InDesign и Quark XPress. CorelDraw — векторный редактор, хотя и с примитивными возможностями многоколоночной верстки в виде текстовых фреймов и TextFlow между ними.
Все это достаточно дорогие пакеты, так что MS Publisher для какой-нибудь газеты для города в 50-100 тыс. населения — самое то. Это если не хочется попробовать вполне удобный бесплатный Scribus, который делался под влиянием старых версий Quark XPress.
А так — извратов видел немало, даже сверстанную в MS Excel газету из какого-то села…
И графический «макет рекламы» (несколько стандартных цветных геометрических фигур и объемная надпись фирмы-заказчика) в Discreet 3DS Max приносили…
По-нормальному верстают в издательских системах / системах для верстки.
Это Adobe InDesign и Quark XPress. CorelDraw — векторный редактор, хотя и с примитивными возможностями многоколоночной верстки в виде текстовых фреймов и TextFlow между ними.
Все это достаточно дорогие пакеты, так что MS Publisher для какой-нибудь газеты для города в 50-100 тыс. населения — самое то. Это если не хочется попробовать вполне удобный бесплатный Scribus, который делался под влиянием старых версий Quark XPress.
А так — извратов видел немало, даже сверстанную в MS Excel газету из какого-то села…
И графический «макет рекламы» (несколько стандартных цветных геометрических фигур и объемная надпись фирмы-заказчика) в Discreet 3DS Max приносили…
А можно поподробнее раскрыть тему замены jira на bugzilla и многократного ускорения заведения тикетов? За счет чего?
История нашего сотрудника, который ранее работал в той компании. Цитируем прямо дословно:
«Дано: 4 продукта в разработке, тест-планы по 200-300 пунктов на каждый. Был отдел тестирования А, 9 человек, работали с Jira как багтрекером, насоздавали полей и сущностей, которые не использовали. В течение года по многим причинам (в том числе из-за факапа с важным клиентом) сменили весь отдел — тогда появились мы, расширились до 12 человек. Насоздавали своих сущностей. Сменился начальник R&D. Через некоторое время вот что обнаружили:
— сущностей стало слишком много, интерфейс потяжелел — затруднился поиск багов и событий
— весь остальный стек был не атлассиановский
— мы начали внедрять Scrum и „монстра“ мешала в процессе
— самое ужасное — перегруженная система стала тормозить.
Мы не хотели ничего менять, но кто-то вспомнил, что работал с Багзилой. Накатили перед одним релизом и полностью испробовали на нём: всем понравилась структура, все эти прозрачные вехи, милестоуны, статусы. Накатили ещё и Bugzilla TODOs, правда, не зашло. Довольно долго пользовались параллельно, что-то перетащили. В итоге работать стали реально в разы быстрее.
Выводы? Отчасти хороший инструмент Jira загубили кучей настроек, которые хотелось применить, отчасти не подошла её философия. Миграция была сложной, если этот процесс вообще можно было назвать миграцией. Но ехать на помирающей лошади тоже не стоит, даже если ты её сам и загнал.»
«Дано: 4 продукта в разработке, тест-планы по 200-300 пунктов на каждый. Был отдел тестирования А, 9 человек, работали с Jira как багтрекером, насоздавали полей и сущностей, которые не использовали. В течение года по многим причинам (в том числе из-за факапа с важным клиентом) сменили весь отдел — тогда появились мы, расширились до 12 человек. Насоздавали своих сущностей. Сменился начальник R&D. Через некоторое время вот что обнаружили:
— сущностей стало слишком много, интерфейс потяжелел — затруднился поиск багов и событий
— весь остальный стек был не атлассиановский
— мы начали внедрять Scrum и „монстра“ мешала в процессе
— самое ужасное — перегруженная система стала тормозить.
Мы не хотели ничего менять, но кто-то вспомнил, что работал с Багзилой. Накатили перед одним релизом и полностью испробовали на нём: всем понравилась структура, все эти прозрачные вехи, милестоуны, статусы. Накатили ещё и Bugzilla TODOs, правда, не зашло. Довольно долго пользовались параллельно, что-то перетащили. В итоге работать стали реально в разы быстрее.
Выводы? Отчасти хороший инструмент Jira загубили кучей настроек, которые хотелось применить, отчасти не подошла её философия. Миграция была сложной, если этот процесс вообще можно было назвать миграцией. Но ехать на помирающей лошади тоже не стоит, даже если ты её сам и загнал.»
мы начали внедрять 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.
Уже неактуально?
Ответ:
«Как раз был 2012 год — и в марте Мозилла выпустила такой вот релиз. Решение было прямо скажем так себе. Потом появились ещё аддоны, но к тому времени мы решили, что со Scrum в чистом виде у нас не сложится :-) В итоге так и работали, что-то от скрама, что-то от водопадной модели.»
«Как раз был 2012 год — и в марте Мозилла выпустила такой вот релиз. Решение было прямо скажем так себе. Потом появились ещё аддоны, но к тому времени мы решили, что со Scrum в чистом виде у нас не сложится :-) В итоге так и работали, что-то от скрама, что-то от водопадной модели.»
Хотелось бы ещё раз обсудить тему KPI для программистов. Это ведь действительно проблема для бизнеса — вычислить количество полезной работы, которую произвёл программист. Деятельность творческая, иногда и «плевание в потолок» — важная часть рабочего процесса. Мои предположения таковы:
1) Задача и время. Ставится цель и адекватные сроки для неё. Если программист или команда справились досрочно — молодцы, получают премию. При этом что и как происходит в процессе — не изучается, даже если разработчик еле протрезвел за полдня до дедлайна. Главное — в отведённый срок выполнить поставленную задачу.
2) Комплексный KPI. Учитывать всё понемногу: и число строк кода, и вес кода, и потраченное время. В этом случае будет невозможно накрутить показатели путём построчной «маяковщины» или искусственного затягивания сроков, поскольку каждый показатель в отдельности имеет небольшой вес и не вызывает желания накручивать.
1) Задача и время. Ставится цель и адекватные сроки для неё. Если программист или команда справились досрочно — молодцы, получают премию. При этом что и как происходит в процессе — не изучается, даже если разработчик еле протрезвел за полдня до дедлайна. Главное — в отведённый срок выполнить поставленную задачу.
2) Комплексный KPI. Учитывать всё понемногу: и число строк кода, и вес кода, и потраченное время. В этом случае будет невозможно накрутить показатели путём построчной «маяковщины» или искусственного затягивания сроков, поскольку каждый показатель в отдельности имеет небольшой вес и не вызывает желания накручивать.
Ни то ни другое разумеется не работает. Поэтому и появились эти ваши Аджайлы/Скрамы и Сторипойнты.
Появились Аджайлы и Скрамы, конечно же не поэтому, а потому, что традиционное проектное управление плохо подходит для проектов с высокой долей неопределенности. По сути, это ответ индустрии на ситуацию, когда 70% проваливались или не укладывались в бюджет.
KPI гибким методологиям не противоречит. Например, есть такой KPI, как процент успешно выполненных спринтов (с точки зрения достижения целей).
Сторипоинты — это альтернатива оценки трудоемкости задачи в человеко-часах. Прямой связи с KPI не вижу.
KPI гибким методологиям не противоречит. Например, есть такой KPI, как процент успешно выполненных спринтов (с точки зрения достижения целей).
Сторипоинты — это альтернатива оценки трудоемкости задачи в человеко-часах. Прямой связи с KPI не вижу.
Эффективность кода оценить очень сложно. Как в любом творчестве, здесь необходимо оценивать с 2-х сторон. 1 — объективная сторона, т.е. факт того, что поставленные формальные цели достигнуты в срок, программа или модуль работает, нужный результат выдает. 2 — субъективная сторона, т.е. программа написана эффективно с грамотным кодом, возможностью наращивания функционала, имеет красивый и удобный интерфейс, заказчику оч. понравилось как исполнение, так и взаимодействие с группой разработки во время работы над проектом.
Если оценка в KPI будет зависеть от набора этих объективных и субъективных параметров, которых может быть далеко не 2, а гораздо больше, то это и будет, на мой взгляд, самый правильный способ оценить качество работы программиста.
Что значит «оценка в KPI»? KPI может быть несколько (или даже несколько десятков), т.к. целей у организации может быть несколько.
Речь о пересчете показателей в компенсационный пакет?
Речь о пересчете показателей в компенсационный пакет?
Совершенно верно. Если Вы используете KPI для мотивации персонала, то можно пересчитывать показатели в деньги. Однако ни один компьютер не сможет оценить уровень удовлетворения клиента от взаимодействия с группой разработки. Для этих целей обычно применяют людей, которые путем опроса клиентов прямо или неявно определяют уровень лояльности и проставляют это уже опираясь на свои субъективные ощущения, например, в свойства проекта. А KPI может подхватывать данные уже из проектов и чисто математически считать компенсации.
Вот так сразу целое направление Digital, когда человек исключается как промежуточное звено в продаже товаров или услуг, стало неактуальным?
Скажем, для подсчета NPS (Net Promoter Score) можно вполне себе обойтись без людей — именно по этой причине опрос встраивают в сам интерфейс.
Не так давно гремели «диванные войны» вокруг Кинопоиска, когда пользователям не понравились изменения. Оштрафовать всех разработчиков, приложивших руку?
Скажем, для подсчета NPS (Net Promoter Score) можно вполне себе обойтись без людей — именно по этой причине опрос встраивают в сам интерфейс.
Не так давно гремели «диванные войны» вокруг Кинопоиска, когда пользователям не понравились изменения. Оштрафовать всех разработчиков, приложивших руку?
Это ведь действительно проблема для бизнеса — вычислить количество полезной работы, которую произвёл программист.
Ну вообще, при нормально настроенной системе KPI оценивается достижение целей или результаты, а не «количество полезной работы».
Например, результат работы отдела продаж оценивается по выручке, а не количеству звонков или других контактов с потенциальными клиентами.
Т.к. цели у бизнеса могут быть разные, то и проблемы у организаций разные. Очень часто эпик фейлы случаются как раз на этапе целеполагания.
Очень простой пример: один разработчик 2 месяца по 60 часов в неделю пилил свой велосипедик для решения задачи, второй нашел стороннюю библиотеку и за день прикрутил ее к проекту, а третий убедил заказчика, что данный функционал вообще не нужен. Кто из них больший молодец? Изменится ли ответ на этот вопрос спустя 2 года?
Например, результат работы отдела продаж оценивается по выручке, а не количеству звонков или других контактов с потенциальными клиентами.
Разрешите не согласиться. Процесс продажи — это сложный многоступенчатый процесс, состоящий из нескольких этапов (если это только не продажа водки в ларьке). Поэтому для достижения цели необходимо бороться за эффективность работы на каждом из этапов, в том числе и на этапе холодных звонков и первых контактов. Это же классическая воронка продаж.
Соглашусь, что я привел очень простую модель.
Продаж чего и в каком сегменте?
Если холодные звонки так важны, почему их часто отдают на аутсорсинг или вообще используют ботов?
Массовые продажи не только в ларьках, но и в интернете вполне себе обходятся без холодных звонков — слишком дорогой инструмент для розницы со сделками на небольшие суммы.
Во в целом, это офф-топик к вопросу KPI, не говоря уж про саму статью.
Это же классическая воронка продаж.
Продаж чего и в каком сегменте?
Если холодные звонки так важны, почему их часто отдают на аутсорсинг или вообще используют ботов?
Массовые продажи не только в ларьках, но и в интернете вполне себе обходятся без холодных звонков — слишком дорогой инструмент для розницы со сделками на небольшие суммы.
Во в целом, это офф-топик к вопросу KPI, не говоря уж про саму статью.
Sign up to leave a comment.
Культура использования ПО в компании