Правильное техническое задание (оно же ТЗ) - какое оно?
Грубо, оно должно содержать ответы на 2 вопроса:
1. ЧТО мы хотим получить?
2. КАК это должно быть сделано?
Т.е. состоять из двух больших частей.
Очень часто сталкивался с тем, что в отдел разработки заходили "типа ТЗ", в которых была только первая часть. Описание того, что хотим. Иногда с умными формулами, эскизами страниц, диаграммами процессов...
Мы их называли "хотелки".
К пастуху, пасущему стадо овец, подъезжает на машине мужик,
высовывается из окна и говорит:
- Если я тебе скажу, сколько у тебя овец в стаде не выходя из машины, ты мне подаришь одну?
Немного удивленный пастух отвечает:
- Хорошо.
Тогда этот мужик достает ноутбук, подсоединяет его к мобильному телефону, устанавливает связь с Интернетом, заходит на сайт НАСА, выбирает спутниковую связь GPS, выясняет точные координаты места, где он находится, и отправляет их на другой спутник НАСА, который сканирует эту местность и выдает фото со сверхвысоким разрешением.
Затем этот он передает снимок в одну из лабораторий Гамбурга, которая через несколько секунд отправляет ему письмо с подтверждением того, что снимок был обработан и полученные данные сохранены в базе данных. Через ODBC он подключается к базе данных MS-SQL, копирует данные в таблицу EXCEL и начинает производить расчет. Через несколько минут он получает результат и распечатывает в цвете 150 страниц на своем миниатюрном принтере.
Я узнал о ментальных картах, когда один из учредителей холдинга, в котором я работал, порекомендовал мне книгу Тони Бьюзена "Супермышление".
Найти ее можно например здесь.
Книга мне не очень понравилась - мне показалось, что она немного затянутая, много повторений одного и того же.
А идея классная.
Отличная штука для записи итогов встречи, пришедших мыслей и идей.
Кроме того, что в ментальные карты можно быстро и удобно вносить информацию, их еще очень быстро и удобно читать.
Нужно просто попробовать, и этот инструмент или подход останутся в Вашем арсенале. Не факт, что будете его использовать для всех случаев, но иногда он сможет быть полезным или даже незаменимым.
Есть несметное колиечство историй о том, как достичь успеха.
Книжные полки магазинов ломятся под тяжестью "историй успеха" именитых компаний.
Аналогичная ситуация в онлайн магазинах.
Это интересно читать. Это дает некое понимание того, "Как может быть". Только эту картину обязательно нужно дополнять для себя историями неудач. На одну "выстрелившую компанию" сотни неудачных стартов. То, что сработало для одних, не сработает для других.
Здесь тоже работает систематичекая ошибка выжившего, только "не выжившие" могут рассказать свою историю. Заметок о неудачах меньше, чем историй успеха, но они тоже есть.
До того, как я прочел заметку ранее неизвестного мне автора В. Кочергина, я считал, что этими двумя направлениями: описанием успеха и описанием неудач, тема раскрывается.
Но нет! Жанр "Вредных советов" жив.
Жили в лесу мышки, и все их обижали.
И решили они просить совета у мудрого филина. Пришли и говорят:
— Мудрый филин, помоги советом. Все нас обижают, мы маленькие.
Что нам делать?
Филин подумал и говорит:
— Отрастите колючки. Тогда вы станете как ежики, а ежики хоть и маленькие, но они с колючками и их никто не обижает.
Мышки обрадовались и побежали домой. Но по дороге одна мышка сказала:
— Как же мы отрастим колючки?
И все побежали обратно, чтобы задать этот вопрос мудрому филину.
Прибежали и спросили:
— Мудрый филин, а как же мы отрастим колючки?
И ответил им филин:
— Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь.
Анекдот
Все, что описано ниже – компиляция того, что я видел в разных компаниях за время своей карьеры. Причем не только в тех, в которых я работал, а и в тех, с которыми взаимодействовал в т.ч. в рамках консалтинга. Да, это в т.ч. (но не только) мои грабли.
***
Не стоит ждать чуда.
Волшебной таблетки не существует.
Никакой бизнес-аналитик (внешний, внутренний) не придет и за неделю (месяц) не найдет простое и быстрое решение, которое сократит затраты втрое и увеличит вдвое прибыль.
Этот пост не о том, что аналитики бесполезны, что анализом и оптимизацией бизнес-процессов не нужно заниматься. Он про другое, больше про то, что "один в поле не воин", что реинжиниринг бизнес-процессов - это совместная работа всех: первого лица, ТОП менеджеров (я их часто дальше буду называть функционалами, подразумевая под этим руководителей подразделений) и, конечно, аналитика.
Этот пост, на конкретных примерах, в т.ч. на моем личном, расскажет о некоторых ошибках организации внутреннего консалтинга. Надеюсь, это будет полезно тем, кто предпочитает бегу по граблям анализ чужих ошибок.
Господи, дай мне силы изменить то, что я могу изменить,
дай мне мужества принять то, что я не в силах изменить,
и мудрости отличить одно от другого
(предположительно) Рейнхольд Нибур
Бывали у Вас ситуации, когда Вы были обижены на своего работодателя?
"Да я столько сделал, никто это не ценит. Никому это не надо. Все!!! Держите меня семеро, я ухожу".
Или наоборот, Ваш подчиненный сделал по собственной инициативе какую-то большую работу, гордо демонстрирует результат труда, а Вы понимаете, что:
- контролировать нужно было чаще, давать больше обратной связи;
- оно в общем-то и не нужно, есть вещи поважнее и понужнее, шансов запустить это - ноль.
Это, наверное, один из самых сложных постов. Потому, что в том числе, через собственные шишки, потому, что сложно до конца осознать, потому, что это связано с выгоранием...
Начну с двух историй, а потом сведу их воедино и дополню абстрактными примерами.
- Фу! До чего же дичь пошла бестолковая — я полдня за ней бегал, чтобы сфотографировать!
- Это ещё мало, теперь ты ещё за ним полдня бегать будешь.
- Это почему же?
- А чтоб фотографию отдать.Каникулы в Простоквашино
Все нижесказанное я писал относительно сферы внутренней разработки и поддержки.
Когда задач много, а ресурса ИТ на всех не хватает.
Я несколько раз наступил на эти грабли сам. Слышал много историй от коллег.
Близкими проблемами являются "Никому не нужный подвиг" и "Супер-аналитик оптимизатор".
Теперь суть:
Разработка выполняется только тогда, когда есть заказчик, а у заказчика выявлена четкая потребность.
Любая строчка кода пишется только тогда, когда заказчик готов тратить время и силы на:
Только тогда, когда выполнены указанные выше условия, можно тратить время программистов на разработку, а аналитиков на составление ТЗ.
В противном случае у вас есть огромный шанс уподобиться Шарику и бегать за дичью пользователями и при составлении ТЗ и, самое неприятное, при внедрении.
Ниже реальные кейсы с граблями (и не только моими). Все имена изменены, все совпадения случайны.
Минимально жизнеспособный продукт (minimum viable product, MVP) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями
Сейчас очень много статей на тему. Большая часть из них посвящена стартапам и продуктовым ИТ компаниям.
Но MVP - это очень полезная в разработке вещь вообще.
И здесь я поделюсь опытом применения концепции MVP в рамках разработки в сервисных подразделениях не ИТ компаний.
Итак, у нас есть разработчик (и возможно даже не один).
Вы их руководитель.
Они на окладе и у вас не болит голова от того, чем им платить в конце месяца зарплату.
И у вас есть заказчики. Внутренние, но от этого не менее важные и любимые :-)
И однажды у кого-то в компании рождается мысль, а давайте разработем продукт Х.
Так, желаение заказчика есть, у него есть полномочия и он готов работать.
Поехали.
В рамках организации складской логистики был интересный случай.
В2В сегмент. Отдел продаж. В нем под два десятка менеджеров. У каждого десятки клиентов.
Так вот, сырье для будущих заказов должны были планировать по себе менеджеры сами.
У компании был план продаж "в деньгах", чтоб "менеджеры тянулись". А вот перевести этот план в конкретные продуктовые позиции уже возможности не было. Спецификаций продукции как таковых утвержденных и формализованных не было. И, соответственно, ни о каких планах производства и закупок, построенных на его основании, речь не шла.
Был операционный план производства - на основании уже полученных заказов С горизонтом максимум в 2 недели. Но, на его основе, даже если бы были спецификации, управлять остатками сырья нельзя, так как плечо поставки по многим позициям - месяцы.
А сырье на основании чего-то закупать надо?
Компания ничего нового не изобрела в этом вопросе: нельзя рассчитать - пойдем "экспертным путем". И, как уже было сказано, план закупок сырья каждый менеджер отдела продаж формировал себе сам.
Сам прикидывал какие заказы должны быть в следующем месяце. Сам делал допуски и страховые запасы...
В KPI такого менеджера были продажи, дебиторка... Все, как у всех... Вот только никакой мотивации на минимизацию остатков.
Периодически конечно генеральный всех теребил за "большой склад". И после этого склад немножко "сдувался". На время.
Но система не менялась. И склад был большим. И имел тенденцию к росту.
В сырье на складе было "заморожена" внушительная сумма.
"Видишь звезду - уволь ее.
Подготовься насколько сможешь и уволь ее. Как можно быстрее.
От звезды больше проблем, чем пользы.
Это сейчас ты думаешь, что это ценный кадр и незаменимый сотрудник.
Что он тянет на себе огромный пласт работы и его не получится никем заменить.
Что это находка.
Но это не так, по факут это проблема. Только отложенная."
Примерно такими словами учил меня один из моих руководителей. Я старался его понять, но принять это мне было сложно - я еще ни разу к тому моменту не сталкивался со звездными сотрудниками и звездным шантажом.
А бывали ли у вас ситуации, когда вам поручают какой-то нудный, рутинный, сложный и долгий проект?
Я говорю о внутренних пректах сервисной разработки.
Именно проект и именно долгий.
Поручают, а потом о нем просто забывают.
Вернее руководство помнит, что вы что-то там делаете, даже нужность этого признает. Но проектом не интересуется. Результаты пректа для него не очень нужны и интересны.
И все...
Заметность, в понимании авторов Стратоплана, строить не на чем.
Рузультат вроде как и есть, но он никому не нужен.
Демотивирует жутко.
Мне доводилось слышать, что некоторым людям приходилось уходить из компании по истечении какого-то срока с таким проектом.
В итоге чаще всего проект закрывали. Ибо ни у кого не было желания что-то продолжать делать в этом направлении.
Еще во времена студенчества преподаватель посоветовал почитать "Отель" и "Аэропорт".
С этого и начлаось мое знкомство с жанром производственного романа в целом и с творчеством А. Хейли в частности.
После "Отеля" и "Аэропорта" был "Окончательный диагноз, затем "Колеса", "Менялы" и "Перегрузка".
Было очень интересно находить новые произведения.
В числе последник прочел "Сильнодействующее лекарство", "На высотах твоих" и "Детектив".
Все это стоит прочесть.
