Alexander Shirokov
Понемногу тема работы с обратной связью клиентов проникает в компании, то сообщение пришлют с опросом, то бумажку для написания отзыва передадут. Занятно, что некоторые компании просят сразу без разбора оставить отзыв на Яндекс Картах - камон, вы прям настолько в себе уверены? Хочется верить, что индустрия будет развиваться
Человек не-идиот обычно старается экономить своё время и подобные инструкции неплохо этому способствуют. А вот токсичные комментарии - не очень)
Финляндия как страна для релокации - это такое себе, конечно. Но за описание спасибо - познавательно.
Не так оно всё радужно, как написано) Был участником и свидетелем внедрения множества систем в том числе по описанной методологии и вот что не так (применимо для среднего и крупного бизнеса, в мелком может быть иначе, не сталкивался).
1. Наличие ТЗ не слишком сильно влияет на успех самого внедрения. В плюс-минус большом проекте ваш документ будут читать несколько человек и каждый поймёт его по своему. На десятом цикле правок и согласований, половина из согласующих перестанет читать документ, потому что они на это не подписывались и будут либо морозиться, либо принимать его не глядя. Потом они же вполне могут заявлять, что продукт сырой, многие требования не покрыты и так далее. Подписанное сторонами ТЗ немного увеличивает шансы на выигранное дело в суде, но не думаю что небольшая компания-интегратор мечтает судиться с условной Икеей.
2. ТЗ в 20-30 страниц это немного наивно) Даже задание на создание небольшого внутрекорпоративного сервиса с внятным описанием внутренней логики и интерфейсов занимает минимум 60-70 страниц с тенденцией уходить в бесконечность, а с серьезными системами с кучей интеграций всё обстоит еще хуже.
3. Вы не пишете ТЗ из воздуха, вы пытаетесь анализировать бизнес-процессы клиента (в идеале конечно). А для этого вы общаетесь с сотрудниками клиента, один из которых как назло в отпуске, второй вечно в командировке, третий не понимает чего вы от него хотите, четвёртый не может понятно ответить на вопросы и вечно уходит в пространные объяснения, перемежая их байками из жизни. В результате в ТЗ попадает процесс в некоторой степени похожий на настоящий. С интеграциями и ролями та же история, всегда есть какая-нибудь Маша, которую забыли занести в матрицу ролей, но без которой ни черта работать не может и не будет.
4. Следствие из п.3. На анализ, беседы, согласования правок, слёзы, панику и финализирование ТЗ легко может уйти от 3х месяцев до полугода (а в случае какого-нибудь ERP и год не удивит). За это время анализируемый бизнес немножко изменится 😊Кто-то внедрит новую систему с которой вам нужно будет в последний момент интегрироваться, кто-то чуть-чуть переделает смежный процесс, кто-то из числа ваших респондентов уволится и не сможет рассказать что он имел ввиду, когда описывал как должна работать фича. Факт в том, что ТЗ устаревает через день после его написания.
Есть еще куча подводных камней, которые тянут на полноценную статью, но резюмируя – имхо, ТЗ это в очень маленькой степени гарантия успеха внедрения или разработки. Это скорее фильтр при входе в проект для обоих сторон. Если заказчик может внятно сформулировать и написать что, как ему сейчас кажется, ему нужно – это плюсик к тому чтобы входить в проект. Для этого в целом и юзер-стори подходят, их внятно описать тоже не каждый в состоянии. Гораздо больше проекту помогут грамотная работа с клиентом (очень редкая штука в наших краях), риск- менеджмент и седовласый ПМ, который заработал первый инфаркт в 27 лет на проекте в ДальГазСтройАвтоматизации и спустя годы имеет чуйку на проблемы и способы их решения. Но в век аджайла все почему-то верят в ТЗ)
В любой компании есть ценности, даже там где они формально не описаны. Ценности помогают собирать в кучу людей, которым комфортно работать вместе. К примеру, в одной из компаний трудоголизм практически в явном виде считается ценностью и добродетелью. Если вы любитель работать с 9 до 18, вам там вряд ли будут очень рады. В другой - наоборот следят чтобы люди работали строго в отведённое время и если вы любите задержаться в офисе и поковыряться в чем-то, на вас будут немного косо смотреть (коллеги, не hr).
Где-то ценят командную работу, где-то индивидуальные результаты, где-то курят кальян и пьют вискарь после работы, где-то бегают марафоны. Проблема начинается тогда когда есть большой разрыв между декларируемыми и настоящими ценностями. Когда официально компания хочет одного, а фактически поощряет другое, процветают лицемерие и корпоративные игры. Есть у этих жанров и свои ценители конечно:)
Имхо, в статье много передёргиваний. Если бизнес развивается, то регламенты очень быстро устаревают и их поддержка становится отдельной задачей - один раз их написать точно не получится. А отправлять людей читать устаревшие регламенты вместо того, чтобы вникнуть в проблему скорее убьет эффективность чем повысит её. Плюс, есть хороший шанс получить кучку биороботов, которые не способны решить задачу, если она хоть на полбуквы отличается от той, что описана в регламенте. Наблюдал две компании в одном сегменте, которые примерно в одно время начали развиваться и одна из них была как раз про регламенты и процессы, а вторая про культуру и людей. Победила вторая.