Хорошая статья. Мне это очень близко. Я умирала над проектами, а мои сотрудники были в расслабленном состоянии или делали что-то неважное. Хорошо, что продлилось это не долго. Для себя определила 2 вещи:
1. Нужно просто сделать это. Просто сменить у задачи ответственного. Сказать — это твоя задача. Если трудно решиться и не хочется этого делать — нужна только секунда, чтобы сказать эту фразу, просто скажи её. После чего нужно убедиться, что задача понятна — но тут как обычно.
2. Делегировать правильному человеку. Даже если с меньшим опытом, но он умеет находить решение, пусть и сильно дольше, чем ты, пусть не так «идеально», как ты. Как проверить — дать несколько своих задач: справляется — давать больше, на усложнение. Не справляется — поручить другую работу или расстаться — здесь тоже нужна решимость. У наших молодых руководителей сейчас 2 основные проблемы: неумение делегировать и боязнь принимать кадровые решения.
Если разработчик сидит на совещании — он не работает.
Разработчики участвуют в оценке проектов, в подготовке технического решения (не всегда это может сделать аналитик и не всегда он есть), должны уметь доносить результаты своей работы, объяснять свои идеи — для меня, и как для разработчика, и как для руководителя, это наиболее эффективный способ. Вы просто не зовите их на все совещания.
Составить план, контролировать его выполнение. Это задачи довольно простые, и их может исполнить любой мало-мальски дисциплинированный человек.
Если бы так, то факапов со сроками и качеством было бы гораздо меньше. Помимо дисциплины необходим навык управления командой, процессом, работы с мотивацией, интуицияопыт, авторитет на основе знаний. Здорово, если всё идёт «как по маслу», и не нужно принимать сложных решений, когда что-то идёт не так — но это отрыв от реальности.
При этом вы говорите:
Поэтому потрудитесь распределить задачи качественно, чтобы избежать неприятных сюрпризов.
Это не может делать просто «любой мало-мальски дисциплинированный человек» — проверено. Вы сами себе противоречите.
Решение защищает его автор. Как правило, это менеджер проекта. На встрече присутствует МП, продавец, и иногда профильный специалист, если проект технически непростой.
По статистике — в целом удовлетворяет. На третьей встрече ведётся 2 списка: «окончательные правки» и «идеи». У нас есть 3 дня для мелкого проекта, чтобы закрыть пункты из первого списка, или неделя для среднего.
Наш лучший результат — 1 пункт в первом списке, который разработчик из офиса закрыл прямо во время встречи.
Смешиваем, поступая интуитивно, ситуативно, с перевесом в ту или другую методологию, клиенты и проекты разные.
В чистом виде SCRUM не получается делать, т.к. приходится переключаться между проектами в середине спринта по разным причинам: то согласование дизайна страницы задержали, потому что клиент уехал в Китай по делам, то предоплату по спринту, то проектов несколько параллельно, приходится перебрасывать ресурсы. Поэтому, если это SCRUM, то SCRUM через Ж. Это всё не от хорошего управления, конечно.
Ещё практикуем, как мы называем, «Сайт за 3 встречи» — это водопад с минимальным задействованием клиента и максимальной самостоятельностью команды. 3 встречи — 1. интервью, чтобы узнать бизнес, задачу, видение клиента, задача максимально разговорить, 2. презентация и защита решения, 3. презентация и защита готового результата. Между 1 и 2 команда придумывает и проектирует решение. Между 2 и 3 реализует решение. Это рискованный формат, делаем только с некоторыми клиентами, в основном не с новыми, для некрупных проектов.
Подходит для клиентов, которым нужен результат, а не то, как мы его будем достигать. Плюс для клиента — он экономит время, ответственность на подрядчике. Плюс для нас — свобода выбора инструментов, нет череды длительных согласований (сначала ТЗ, потом контент-план, потом прототипы, потом дизайн).
Из онлайн сервисов могу порекомендовать Read the Docs, и как средство документирования — Генератор документации Sphinx. Если нравится формат wiki, то посмотрите DokuWiki. Может кто-то в комментариях что-то ещё добавит.
Мы у себя используем Sphinx, но не на Read the Docs, а отдельно на нашем сервере. Ещё сделали к нему веб-морду, чтобы с редактором могли работать не только разработчики, но и все сотрудники.
Да, он развивается не так интерсивно, как Yii или Laravel. Но развивается. Вот репо 4 версии: https://github.com/bcit-ci/CodeIgniter4. Новость о выходе релиза Pre-Alpha 1 http://blog.newmythmedia.com/blog/show/2016-06-25_Getting_Started_With_CodeIgniter_4_Pre-Alpha_1, вторая фаза почти завершена. С архитектурой у меня и коллег проблем не было. Тестами пользовалась ещё когда была вторая версия. Масштабируем его активно, пример — модульность, HMVC, можно брать и прикручивать либы из других фреймворков, если нужно. С автокомплитом решили тоже ещё со второй версии, работали в нетбинсе, сейчас в phpstorm.
У проекта закрытый код, в общий доступ не выкладываем, сам по себе инструмент не планируем распространять. Демо версии отдельно нет, потому что для клиентов в продажах работает лучше всего — это показать уже готовый сайт реального клиента, который максимально близок — им важен не инструмент, а конечный результат, который решает задачу бизнеса.
Думала в будущей статье рассказать про то, как мы сделали модуль SEO, благодаря которому наши сайты проходят аудит у конкурентов. Там без демо не обойтись и техническое решение частично нужно показать. Тема интересна?
На тот момент на Modx довелось поработать, Vue ещё не был в поле моего зрения. Но суть не в этом. После рассмотрения нескольких фреймворков и CMS я остановилась на том, что для меня быстрее и лучше всего решит мою задачу. У меня были проекты на фреймворке, 3 года опыта работы на нём на тот момент, сформировалась большая база кода.
Наверняка, на большинстве инструментов можно сделать хороший кейс, если компания на этих инструментах специализируется. В мой пример вы можете подставить любые технологии, если для вас они подходят лучше всего.
В статье указано, что 100 часов — это «Ресурсы для первого релиза» в условиях совета «Не ставьте слишком больших целей для первого релиза.». В первом релизе было только необходимое на тот момент — абзац «Первый релиз». Я прорабатывала ядро, джун подключился на модулях. Джун работал уже с нами какое-то время, умел пользоваться инструментами, знал фреймворк, поэтому учить уже не пришлось. Плюс, у нас к тому моменту была достаточная база своего кода, поэтому частично использовали наработки.
По самому первому релизу уже нет скрина, но одна из первых версий админки выглядела примерно так: скрин. Там было далеко не всё хорошо и правильно.
С тех пор прошло года 2, за всё время развития CMF было потрачено гораздо больше, чем 100 часов. Это процесс непрерывной разработки, который будет продолжаться. Всегда есть, что исправлять и улучшать.
Контекст моего примера — разработка сайтов для автодилеров. Как правило, они небольшой или средней сложности. Но у этого направления есть свои особенности — набор разделов, модулей (у всех есть модельный ряд, у части есть авто с пробегом), требований дистрибьютора к сайту автодилера. И при этом требования могут сильно отличаться, они просто разные у каждого бренда, модельный ряд по структуре контента тоже сильно разнится.
Чтобы сделать на поп.движках решение, удобное для клиента и удовлетворяющее требованиям бренда, нужно приложить сильно больше усилий. Мне довелось посмотреть, как мучается клиент с сайтами, например, на вордпресе, друпале и самописках, когда им сверху спускают требования, а их или не могут выполнить, либо это стоит клиенту дороже.
Или есть бренды, для которых дистрибьютор предлагает дилерскую платформу, в которой кроме пары страниц и своих контактов дилер поменять ничего не сможет, а ему нужно делать seo и продвигаться, т.к. он в Москве, и там конкуренция.
Таким образом, нужно что-то своё, быстрое, легковесное изначально, легко модифицируемое под бренд путём изменения функционала модулей, на базе чего разработчик может быстро развернуть, натянуть верстку, допрограммировать нужный функционал (он бывает очень непростым, конфигураторы, например).
Это если про контекст примера, с которого всё началось. Сейчас наша CMF подходит под множество отраслей.
Зачем же использовать сразу все вопросы) На одной встрече может быть, например, только 10 актуальных вопросов. И только часть из них потребует подготовки. Если нужно спросить о том, «как вы сработали с тестировщиком 3 недели назад» или «сколько в среднем у тебя уходит времени на багфиксы» — нужно их отправить заранее, с ходу на такое трудно ответить. А «Знаешь ли ты про библиотеку компании?» не нужно отправлять, конечно.
Я практикую такие беседы, и пока был только положительный эффект. Всё зависит от того, как вы это делаете. Чаще всего люди понимают, зачем с ними беседуют и воспринимают адекватно. А если после бесед ты что-то предпринимаешь, чтобы решить проблему, то ситуация прямо диаметральна описанной вами.
Какие формальные показатели уже есть у сотрудников поддержки?
1. Легко измеримые: скорость ответа на заявку, решен ли вопрос клиента в срок (в зависимости от условий по договору/тарифа своя норма срока).
2. Трудно измеримые: уровень удовлетворенности клиента (скорость, сервис, профессионализм), использование возможности допродаж (предложить что-то ещё улучшить, посоветовать — в основном, тех.поддержка вокруг сайтов).
Как эта поддержка организована?
На входе 1 человек принимает заявки (фрешдеск). Его задача — держать клиента в курсе дела, выяснить детали, определить исполнителя, держать задачу в фокусе и всегда знать статус. Он определяет исполнителя — кого-то из 2-3 технических специалистов, которые непосредственно решают техническую задачу, или может сделать сам, если задача технически-несложная или относится к контенту (ещё для таких задач есть контент-менеджер «над подхвате»).
Как предполагается отслеживать формальные показатели?
С легко измеримыми всё понятно, мы можем это мерить, со вторыми — не так.
По уровню удовлетворенности — как-то давно проводили анкетирование (один раз). Сейчас руководство хочет ввести анкетирование на регулярной основе, только я считаю, что чаще чем раз в полгода такое делать нельзя. Было бы полезно узнать, как другие у себя это замеряют.
По использованию возможности допродаж — тут кроме как ходить за сотрудникам и субъективно решать «вот тут можно было предложить, а ты не предложил», у меня больше идей пока нет — а это дофига ресурсов и дико демотивирует всех. Думаю, многим покажется странным такое ожидание от отдела тех.поддержки :)
В компании, где я работаю, есть маленький отдел тех.поддержки. Руководство хочет регулярно собирать ОС от клиентов в виде анкетирования с оценкой по шкале разных критериев, и это будет влиять на KPI сотрудников отдела. Вроде бы всё логично, но я думаю, что важнее не цифры, а то, как клиенту с нами нравится работать, и что наш сотрудник ему действительно помогает и хочет помогать.
Как вы считаете, как лучше построить сбор ОС и показатели KPI, чтобы и реальную ОС получить, с которой можно работать, и сформировать правильную мотивацию у сотрудника?
Иметь бы мне это знание года 4 назад, когда я начинала проводить собеседования в качестве тех.специалиста) Надменность, неумение просто поддержать беседу, задать действительно важные вопросы. Чувствовала, что что-то не так. Потом у себя спросила — что, если бы я была на месте этого кандидата. После этого я перестала задавать вопросы типа «чем хотите заниматься через 5 лет» — это глупо, даже если мы ищем человека на 5-летний контракт, или типа «как вы понимаете ООП» — можно 1 раз прочитать определение в двух разных источниках и правильно ответить — лучше попросить показать пример реализации или дать небольшое тестовое задание, если правильное понимание ООП для нас важно.
Ещё сделала для себя вывод — к сожалению, собеседование не очень показательно — часто бывает так, что кандидат себя отлично проявил на собеседовании и даже справился с заданиями, но на стажировке показал себя плохо, или наоборот — после собеседования очень сомневалась брать ли на стажировку, а потом была счастлива, что взяла. Но чем больше собеседований провожу, тем меньше ошибаюсь)
Сейчас для меня собеседование — это 2 одинаково ценных вопроса: 1. какой уровень навыков, 2. какой человек, его взгляды и реакции. Сейчас я уже не готовлю вопросы, просто стараюсь расслабиться и поговорить с кандидатом, к минимуму свести официоз, больше смотрю в глаза, говорю спокойнее. Некоторым сразу предлагаю перейти на «ты», если это уместно. Больше вопросов про практику — прошу рассказать про реализованные проекты/задачи, какие вопросы вставали, как решили, что именно сделали. Прошу рассказать, как человек решают какую-то конкретную типовую задачу (например, проектирует БД под новый проект и строит его архитектуру) — помогает понять, как он думает и умеет ли объяснять свои идеи, умеет ли составлять простой план своих действий. Ещё важно понять, умеет ли человек следовать простым инструкциям — для этого подойдёт даже короткое задание с множеством простых условий.
Information
Rating
Does not participate
Location
Тюмень, Тюменская обл. и Ханты-Мансийский АО, Россия
Забавно написано и картинки повеселили). А главное — так близко к моей реальности, про парочку моих коллег, как ни печально. Спасибо за статью!
Давайте обратно на светлую сторону)
1. Нужно просто сделать это. Просто сменить у задачи ответственного. Сказать — это твоя задача. Если трудно решиться и не хочется этого делать — нужна только секунда, чтобы сказать эту фразу, просто скажи её. После чего нужно убедиться, что задача понятна — но тут как обычно.
2. Делегировать правильному человеку. Даже если с меньшим опытом, но он умеет находить решение, пусть и сильно дольше, чем ты, пусть не так «идеально», как ты. Как проверить — дать несколько своих задач: справляется — давать больше, на усложнение. Не справляется — поручить другую работу или расстаться — здесь тоже нужна решимость. У наших молодых руководителей сейчас 2 основные проблемы: неумение делегировать и боязнь принимать кадровые решения.
Если бы так, то факапов со сроками и качеством было бы гораздо меньше. Помимо дисциплины необходим навык управления командой, процессом, работы с мотивацией,
интуицияопыт, авторитет на основе знаний. Здорово, если всё идёт «как по маслу», и не нужно принимать сложных решений, когда что-то идёт не так — но это отрыв от реальности.При этом вы говорите:
Это не может делать просто «любой мало-мальски дисциплинированный человек» — проверено. Вы сами себе противоречите.
По статистике — в целом удовлетворяет. На третьей встрече ведётся 2 списка: «окончательные правки» и «идеи». У нас есть 3 дня для мелкого проекта, чтобы закрыть пункты из первого списка, или неделя для среднего.
Наш лучший результат — 1 пункт в первом списке, который разработчик из офиса закрыл прямо во время встречи.
В чистом виде SCRUM не получается делать, т.к. приходится переключаться между проектами в середине спринта по разным причинам: то согласование дизайна страницы задержали, потому что клиент уехал в Китай по делам, то предоплату по спринту, то проектов несколько параллельно, приходится перебрасывать ресурсы. Поэтому, если это SCRUM, то SCRUM через Ж. Это всё не от хорошего управления, конечно.
Ещё практикуем, как мы называем, «Сайт за 3 встречи» — это водопад с минимальным задействованием клиента и максимальной самостоятельностью команды. 3 встречи — 1. интервью, чтобы узнать бизнес, задачу, видение клиента, задача максимально разговорить, 2. презентация и защита решения, 3. презентация и защита готового результата. Между 1 и 2 команда придумывает и проектирует решение. Между 2 и 3 реализует решение. Это рискованный формат, делаем только с некоторыми клиентами, в основном не с новыми, для некрупных проектов.
Подходит для клиентов, которым нужен результат, а не то, как мы его будем достигать. Плюс для клиента — он экономит время, ответственность на подрядчике. Плюс для нас — свобода выбора инструментов, нет череды длительных согласований (сначала ТЗ, потом контент-план, потом прототипы, потом дизайн).
Мы у себя используем Sphinx, но не на Read the Docs, а отдельно на нашем сервере. Ещё сделали к нему веб-морду, чтобы с редактором могли работать не только разработчики, но и все сотрудники.
Думала в будущей статье рассказать про то, как мы сделали модуль SEO, благодаря которому наши сайты проходят аудит у конкурентов. Там без демо не обойтись и техническое решение частично нужно показать. Тема интересна?
Наверняка, на большинстве инструментов можно сделать хороший кейс, если компания на этих инструментах специализируется. В мой пример вы можете подставить любые технологии, если для вас они подходят лучше всего.
По самому первому релизу уже нет скрина, но одна из первых версий админки выглядела примерно так: скрин. Там было далеко не всё хорошо и правильно.
С тех пор прошло года 2, за всё время развития CMF было потрачено гораздо больше, чем 100 часов. Это процесс непрерывной разработки, который будет продолжаться. Всегда есть, что исправлять и улучшать.
Контекст моего примера — разработка сайтов для автодилеров. Как правило, они небольшой или средней сложности. Но у этого направления есть свои особенности — набор разделов, модулей (у всех есть модельный ряд, у части есть авто с пробегом), требований дистрибьютора к сайту автодилера. И при этом требования могут сильно отличаться, они просто разные у каждого бренда, модельный ряд по структуре контента тоже сильно разнится.
Чтобы сделать на поп.движках решение, удобное для клиента и удовлетворяющее требованиям бренда, нужно приложить сильно больше усилий. Мне довелось посмотреть, как мучается клиент с сайтами, например, на вордпресе, друпале и самописках, когда им сверху спускают требования, а их или не могут выполнить, либо это стоит клиенту дороже.
Или есть бренды, для которых дистрибьютор предлагает дилерскую платформу, в которой кроме пары страниц и своих контактов дилер поменять ничего не сможет, а ему нужно делать seo и продвигаться, т.к. он в Москве, и там конкуренция.
Таким образом, нужно что-то своё, быстрое, легковесное изначально, легко модифицируемое под бренд путём изменения функционала модулей, на базе чего разработчик может быстро развернуть, натянуть верстку, допрограммировать нужный функционал (он бывает очень непростым, конфигураторы, например).
Это если про контекст примера, с которого всё началось. Сейчас наша CMF подходит под множество отраслей.
Я практикую такие беседы, и пока был только положительный эффект. Всё зависит от того, как вы это делаете. Чаще всего люди понимают, зачем с ними беседуют и воспринимают адекватно. А если после бесед ты что-то предпринимаешь, чтобы решить проблему, то ситуация прямо диаметральна описанной вами.
Спасибо автору за подборку!
1. Легко измеримые: скорость ответа на заявку, решен ли вопрос клиента в срок (в зависимости от условий по договору/тарифа своя норма срока).
2. Трудно измеримые: уровень удовлетворенности клиента (скорость, сервис, профессионализм), использование возможности допродаж (предложить что-то ещё улучшить, посоветовать — в основном, тех.поддержка вокруг сайтов).
На входе 1 человек принимает заявки (фрешдеск). Его задача — держать клиента в курсе дела, выяснить детали, определить исполнителя, держать задачу в фокусе и всегда знать статус. Он определяет исполнителя — кого-то из 2-3 технических специалистов, которые непосредственно решают техническую задачу, или может сделать сам, если задача технически-несложная или относится к контенту (ещё для таких задач есть контент-менеджер «над подхвате»).
С легко измеримыми всё понятно, мы можем это мерить, со вторыми — не так.
По уровню удовлетворенности — как-то давно проводили анкетирование (один раз). Сейчас руководство хочет ввести анкетирование на регулярной основе, только я считаю, что чаще чем раз в полгода такое делать нельзя. Было бы полезно узнать, как другие у себя это замеряют.
По использованию возможности допродаж — тут кроме как ходить за сотрудникам и субъективно решать «вот тут можно было предложить, а ты не предложил», у меня больше идей пока нет — а это дофига ресурсов и дико демотивирует всех. Думаю, многим покажется странным такое ожидание от отдела тех.поддержки :)
Как вы считаете, как лучше построить сбор ОС и показатели KPI, чтобы и реальную ОС получить, с которой можно работать, и сформировать правильную мотивацию у сотрудника?
Ещё сделала для себя вывод — к сожалению, собеседование не очень показательно — часто бывает так, что кандидат себя отлично проявил на собеседовании и даже справился с заданиями, но на стажировке показал себя плохо, или наоборот — после собеседования очень сомневалась брать ли на стажировку, а потом была счастлива, что взяла. Но чем больше собеседований провожу, тем меньше ошибаюсь)
Сейчас для меня собеседование — это 2 одинаково ценных вопроса: 1. какой уровень навыков, 2. какой человек, его взгляды и реакции. Сейчас я уже не готовлю вопросы, просто стараюсь расслабиться и поговорить с кандидатом, к минимуму свести официоз, больше смотрю в глаза, говорю спокойнее. Некоторым сразу предлагаю перейти на «ты», если это уместно. Больше вопросов про практику — прошу рассказать про реализованные проекты/задачи, какие вопросы вставали, как решили, что именно сделали. Прошу рассказать, как человек решают какую-то конкретную типовую задачу (например, проектирует БД под новый проект и строит его архитектуру) — помогает понять, как он думает и умеет ли объяснять свои идеи, умеет ли составлять простой план своих действий. Ещё важно понять, умеет ли человек следовать простым инструкциям — для этого подойдёт даже короткое задание с множеством простых условий.