Технические долги управления

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

    Итак, начало.

    Для решения уравнения давайте определим его составляющие.
    В наличии:
    1.Готовый бизнес, который не шатко не валко, но работает. (Под понятием работает подразумевается функционирует, и мы, пока что, не задаёмся вопросом эффективности, о нём ниже).
    2.Присутсвует команда специалистов, скажем так далеко не «дримтим», но и не самое плохое предложение на рынке, задачи выполняются, и это главный критерий.
    3.Что не маловажно, у нас есть клиенты, и предположим, что их более чем достаточно.
    Казалось бы, разделяй и властвуй! Вот он бизнес, почти эффективный, но как это часто бывает есть один нюанс…
    Нас крайне часто учат на всевозможных тренингах, семинарах, конференциях, книгах, курсах, и так далее – клиент почти всегда прав. Вот это самое почти – далеко не все могут прочувствовать, и дабы повысить лояльность клиента, идут на многие и многие уступки. А бизнес-то, все не идёт, а работы (операционной) становиться-то все больше и больше и больше.

    Добро пожаловать в ад.

    При большом потоке заказов и не осведомлённости отдела продаж о загрузке команды (команд), мы можем иметь очень гадкую картину. Называется она Технические долги.
    Что это такое? Это когда, предположим, существует проект, он уже оплачен по предоплате сразу или частично, и «совершенно внезапно», практически как гром среди ясного неба – клиент исчезает. Он недоступен. Вообще ни как. Ни телефоном, ни письмом, ни каким бы то не было образом – его просто нет на этой планете. А этап – когда он нужен для согласования или принятия работы/этапа. Казалось бы, ну и фиг с ним, да? Денег то он заплатил, значит не куда не денется, и вот этот момент играет со многими из нас крайне злую шутку. Он не денется, в этом, на 90% (статистика личного опыта) вы правы. Но он восстанет, и будет так называемым «клиентом-зомби». Это когда он появляется через полгода, а что ему делали и где остановились толком то ни кто и не помнит. И появляется он не просто так, а хочет кушать. Ваши мозги. Шучу конечно, он просто вспомнил про сайт, который вы создавали, и хочет наконец-то его получить, но мировоззрение/понимание необходимости могло измениться. И задачи у него уже другие совсем. Но суть не в этом. Все можно объяснить, донести, и получить в крайнем случае доплату, ну или играйте с лояльностью. Суть совсем в другом. Вы то эти полгода не стояли на месте, и программист/дизайнер/бэкэндщик уже могут и не работать в вашей компании, а задачи давным-давно канули в лету из любимой системы управления задачами. Да и потом, у вас сейчас есть действующие клиенты, над которыми вы работаете вот прямо сейчас. У вас в конце концов есть финансовое планирование, общий месячный бюджет, и на следующий месяц тоже, и вам ну совсем не в жилу разбираться с этим зомбяком. Вот тут многие из нас и попадают в яму технических долгов. Тут работает принцип дамбы, которую прорвало. При небольших группах (собственно для них и вещаю), невозможно быстро и грамотно перераспределить ресурсы, что бы и на лавку сесть, да и рыбки скушать.
    Смотрите сами. У вас одновременно несколько проектов в работе, и это в общем-то устраивает всех. И вас – деньги идут хорошим потоком, и команду – проекты интересные, и собственного любимого клиента – все делается так, как и должно, и в срок. И остановить ни один из действующих проектов вы не можете, и не можете стопорнуть зомби – он на совершенно законных основаниях может требовать свой сайт. Беда. И мы сразу начинаем перегружать команду, все пилят и день и ночь, потом начинается этап правок и свистелок клиента, потому что, полгода назад ТЗ было другим, и он как бы платит за правки и изменения, но несоизмеримо мало с тем сколько теряете из-за задержек другого проекта вы как фирма. И что делать?

    Отгадка, или рецепт вечно молодости

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


    Если не решить вопрос с техническим долгом быстро – вы будите решать его очень и очень долго, и каждый новый проект, будет отодвигать старый на эту планку. И команда будет вечно работать в режиме цейтнот.
    С другой стороны, казалось бы, договорись с клиентом, и радуйся. А вот нет. Не все идут на уступки, так как и у них и именно сейчас может быть все в огне – им сайт нужен, как рыбе вода. И ждать они ну ни как не могут. Бред конечно, согласен, но к сожалению он имеет место быть очень часто. Способов решить эту задачу есть много, но к сожалению лишь несколько из них работают эффективно. Один из них, я постарался описать.
    Напоследок, дам несколько рекомендаций
    • Создайте базу документов под конкретный проект и поддерживайте их актуальность.
    • Пинайте менеджеров или помните сами, что сделки надо не только открывать, но и закрывать.
    • Учитывайте данные риски в договоре с каждым клиентом, не только со стороны пролонгации сроков за его счёт в таких ситуациях, но и защита собственных бизнес-процессов.

    Благодарю вас за прочтение, и желаю удачи. Не делайте долгов. Технических особенно.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 18
      +2
      > и не можете стопорнуть зомби – он на совершенно законных основаниях может требовать свой сайт

      Это ведь решается договорными (устными или письменными) отношениями… да и тем более если он деньги заплатил.
      «Зомби» бывают и с самого начала, просто их нужно вычислять и натравливать на них хороших «зомби»-менеджеров, которые приучат их к нормальной еде :)
        0
        Это конечно вариант, но вы же изменили условия задачи, которую я описал сразу. Мы действуем именно в её рамках.
          +1
          Извините я вас не понял вероятно сразу… получается задача ради задачи, где есть некая гипотетическая ситуация
          Тогда нужна статья о том как создать благоприятные н/у(начальные условия) чтобы не появлялось зомби.
          Т.е. как правильно открыть проект
            0
            Ок, такая статья томится в черновиках уже полгода, доведу до ума.
            В целом, я взял ситуацию которая встречалась чаще всего на данном рынке, и у меня в том числе, и многие решали её не совсем эффективно, вот я и описал.
        0
        спасибо за статью.
        реквестирую цикл подобных:)
          0
          и вам спасибо за отзыв! Какая тематика вас интересовала бы более других?
            +1
            все в рамках «наблюдений и некоторых рецептов относительно бизнеса создания сайтов» :) в данном деле чужой опыт часто бывает крайне полезен.
              +1
              Вас понял, приготовлю что-нибудь вкусненькое на эту тему, благо шишек набито уже совершенно немыслимое количество). Я имел ввиду вам какую конкретно отрасль интереснее посмотреть? Ведение проектов, продажи (лидогены и программы лояльности), управление бизнесом в целом, работа с командой?
                +1
                пусть будет ведение проектов и управление бизнесом.
                спасибо!
          0
          Наверное еще вариант вернуть деньги?
            0
            Это, конечно вариант, но и он не всегда возможен читайте выгоден). Особенно, если выполнено более 75% работы (опираясь на ТЗ конечно).
            0
            В нашей практике не было клиентов, которые после «воскрешения из мертвых» не понимали бы, что поезд давно ушел и надо начинать все заново. А теперь мы и вовсе разбили весь процесс разработки сайта на три отдельных этапа, каждый по своему договору, только после завершения предыдущего: проектирование, дизайн, разработка — поэтому и ситуация будет попроще, в случае не совсем адекватного клиента.
              0
              Тогда вам можно только искренне позавидовать! ;). Надеюсь, вы ни когда и не узнаете этого сомнительного удовольствия ощущать себя экой Милой Йовович воюющей с тысячей зомбяков. Идея развития этапов в договоры очень клевая, мы собственно поступили почти так же, но несколько с другой стороны — мы этапы прописали в ТЗ, осметили их и закрываем промежуточными актами, я как раз в отдельной статье хотел рассказать про документы.
                0
                Мы просто поняли, что пытаясь угадать стоимость разработки дизайн-макетов до того, как будет написана подробная проектная документация, и стоимость верстки и программирования до того, как будут в наличии те самые дизайн-макеты, мы тычем пальцем в небо. После нескольких серьезных просчетов решили завязывать с попытками осметить весь проект целиком сразу. Мы боялись, что клиенты на это негативно отреагируют, но по факту такой подход лишь подчеркнул наш профессионализм и понимание вопроса.
                  0
                  Я не призывал ни кого отказываться от идеи технической документации. Ваш подход логичен и справедлив, но осметить, на мой взгляд достаточно точно можно и на этапе ТЗ и прототипирования — когда видна вся картина. Тут, к слову идет интересный момент — как вы делаете смету на этап? Исходя из стоимости нормочаса? А нормочас как считаете? Из каких параметров, что закладываете в стоимость?
                  P.s. По моему мы начинаем жестоко оффтопить. ;).
                    0
                    достаточно точно можно и на этапе ТЗ и прототипирования

                    Сложность верстки можно оценить, например, исключительно исходя из макетов. Иногда, при разработке макетов появляются новые, здравые идеи, которые влияют на функционал. Опять же, не только заказчику понятнее проект, когда он видит итоговую картинку, но и разработчикам тоже. Поэтому оценка по ТЗ и макетам всегда будет точнее, чем только по ТЗ.

                    И да, что-то мы уходим от темы статьи. :)
                      0
                      А как же этап прототипирования на котором тоже становиться понятно далеко не мало?
                        0
                        Немало != все.

                        Верстальщику, например, по определению становится понятно все только из макета и никак иначе.

                        Программисту, как правило, хватает макапов, но иногда (иногда) в итоговом макете появляются детали, которые влияют и на функционал тоже.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое