История – одного проекта на «Доверии». Или как большие маленьких обижают

    Одна маленькая, но очень гордая ИТ фирма, работала на субподряде у “монстров” отечественной ИТ индустрии. Начинали свое сотрудничество они еще до кризиса, когда деньги особо не считали, выделяя на разработку столько, сколько нужно. Меряли на глазок, ну примерно вот столько, показывая зазор между большим и указательным пальцами, дающий понять – нужную толщину пачки денег. При таком раскладе, напрягаться с точными расчетами бюджета проекта не было особого резона. Прикинули грубо и побежали. Ошиблись, ну с кем не бывает, технологии все время меняются, заказчик толком объяснить, что ему надо не может. Главное выдержать временные сроки. Чувствуешь, что не успеваешь, привлек еще специалистов и гонишь разработку к сроку. Выходит конечно чуть дороже, но вполне работоспособная схема, всем хватало, и главное голова от проблем особо не болела.

    Но вот по мере углубления кризиса, стали возникать вопросы к бюджету, вернее к его нехватке. Поскольку это случилось, как всегда неожиданно, то сначала в кампаниях зародился некий дискомфорт, пошли склоки, поиски виноватых и наказания невиновных. Всех кого надо конечно наказали, но проблемы почему-то остались. Призадумались тут. Как же дальше жить с этим?

    Опять же, в своей массе специалисты крупных ИТ фирмах знают и умеют грамотно и эффективно верстать бюджеты, но от этого как-то уже постепенно отвыкли, за ненадобностью. Тут же надо напрягаться, как-то брать ответственность, возиться с нюансами, держать руку на пульсе и реагировать, реагировать и реагировать. Короче держать себя и других все время в тонусе. А люди в больших фирмах все сплошь маститые, серьезные и занятые всякими важными делами. Опять-таки все время происходят какие-то совещания, митинги и отвлекаться на такие мелочи как кропотливая работа по оптимизации проектных работ у них уже не остается ни времени, ни сил, а главное желания. Вот тут и происходит разрыв шаблона. Объемы бюджетов уже не те, и чтобы зарабатывать необходимо ежедневно разбираться с мелочами, вникать в нюансы, а делать этого уже ой как не хочется. Какой же выход?

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

    И ответ то вот же, лежит на поверхности – субподрядчик, небольшие ИТ фирмы. Ведь все риски можно спихнуть на них. Пусть они оценивают и озвучивают бюджеты. Не хватает требований от заказчика – проблема субподрядчика. Его можно успокоить: «Да соберем мы тебе потом эти твои требования, по ходу проекта, не беспокойся. А пока прикинь сам, что там может понадобиться, только не увлекайся и проектируй попроще, но надежно, чтобы вышло дешево и сердито. А не хочешь так работать, мы сейчас только свистнем и к нам прибегут команды и выстроятся в очередь».

    И это еще не все. Схема ведь может совершенствоваться. Как еще подстраховаться маститой ИТ фирме? А давайте в договор с субподрядчиком включим пунктик о том, что если заказчика что-то не устроит, то считать это ошибками субподрядчика и возложить на него все затраты по их устранению. И теперь уже будет не важно, что забыли уточнить что-то у заказчика, что не включили что-то в требования, причем не включили именно специалисты той самой маститой ИТ кампании. А зачем им теперь напрягаться? Ведь теперь отвечать за это будет субподрядчик. Не указано что-то в требованиях – ерунда, спишем на ошибки субподрядчика. И пожалуйста не спорьте с заказчиком — бесполезно, он же госструктура. Только вслушайтесь в фразу: «государственный заказ». Как звучит, а? Ну должны же Вы в конце концов понимаете всю ответственность и оказанное Вам высокое доверие! Да и кто подпустит бедного субподрядчика непосредственно к телу заказчика, чтобы напрямую из первых уст узнать и разъяснить все. Ведь там люди находятся на государевой службе и отвлекать их всякими глупостями не суть. Но это все для субподрядчика откроется уже потом, когда силки будут расставлены

    Вот так примерно эта схема и работает.

    А на практике это выглядит вот как. Например, вышеупомянутой небольшой фирме настойчиво предложили выполнить контракт по разработке Автоматизированного рабочего места руководителя (далее АРМ). Тот самый гос. заказ. Предложили старшие партнеры – большая ИТ фирма. Назовем ее Компания «Доверие», а как же без доверия. Из требований, что и как конкретно необходимо реализовать предоставили: 1) Техническое задание на 1,5 листика, 2) картинки — «комиксы» на тему, как должен примерно выглядеть интерфейс пользователя с точки зрения заказчика и 3) отрывки требований к похожим разработкам в других проектах. Со словами: «Ничего тут сложного, это уже 100 раз так делали», оценили затраты, добавили процент на риски, ударили по рукам и побежали. Да, вот еще одна находка сметливого менеджмента Компании «Доверие» — расчет с субподрядчиком должен производиться уже после сдачи готового продукта заказчику, а это приблизительно через 4-5 месяцев после старта. Страховаться так страховаться, ведь как говорил классик: «Полное спокойствие может дать человеку только страховой полис». А если такой подход не устраивает «… мы сейчас только свистнем и к нам прибегут команды и выстроятся в очередь…», ну Вы помните, я уже писал об этом выше.

    И тут еще выясняется, что у заказчика оказывается уже есть работающая система, она его в общем-то устраивает, зачем ему новая, толково объяснить никто не может. Но справедливости ради надо отметить, что один простой аргумент все же нашелся – «А ТАК НАДО!». То есть заказчик не мотивирован: сделаете «суперпупер» систему хорошо, не сделаете, да и черт с ней, будем работать со старой.

    И делать АРМ необходимо не абы как, а на платформе предоставляемой самой Компанией «Доверие», которая мягко говоря к таким фривольностям интерфейса пользователя, как было нарисовано в «комиксах» заказчика, не приспособлена. И соответственно затраты уже вырастают еще процентов на 30%. Но это, как говорено выше – уже проблемы субподрядчика. А еще разрабатываемый АРМ должен взаимодействовать с основной программой, через готовый механизм, разработанный для мобильных решений, и уже используемый с горем пополам, но с кучей ограничений, которые тоже не вяжутся с предполагаемым десктопным решением АРМа. Документация к этому механизму есть (мало, мало), но она частично устаревшая, а частично недостоверная. То есть разрабатываемому АРМу предстоит еще осуществлять интеграцию с основной системой, через некий черный ящик, разработанный «на коленках» и который может часами пыхтеть, синхронизируя данные. Что при этом в нем происходит, почему так долго и как его ускорить, не может рассказать никто, даже его разработчик. Это еще значительно увеличивает затраты проекта. Но менеджеров «Доверия» это уже не волнует – ведь проблема теперь уже не их, а субподрядчика.

    Далее, когда сделали первый прототип и показали заказчику, он с удивлением осознал, что ожидал совсем другого, полностью противоположного увиденному. Нет, предоставленные им «комиксы» с интерфейсом пользователя, полностью соответствовали разработанному прототипу, лицо программы оказалось до боли знакомым. Но выяснилось, что за картинками заказчик предполагал в уме, еще и некий функционал, который по его мнению разработчики сами должны были узреть. А менеджерам «Доверия» уточнять это было недосуг. При этом «Доверие» полностью изолировал субподрядчика от заказчика (как брандмауэром). Замечания и пожелания менеджеры передавали большей частью устно, на бегу, взволнованные после показа, по телефону, перекрикивая ветер и шум машин. Люди то занятые, вот что отложилось в памяти из беседы с заказчиком, то и передали. На всякий случай напомню, что если команде субподряда это не нравится, то «… мы сейчас только свистнем и к нам прибегут команды и выстроятся в очередь…».

    А в это время…, тестировщики Компании «Доверие», получили задание — все как следует оттестировать. И они конечно ринулись в бой. Каково же было их удивление, когда они узнали, что полноценных требований то и нет, а есть только разрозненные куски от других проектов. Огорчились… Но поскольку они работали в Компании «Доверие» уже не первый год, печалились не долго. Напряглись, изловчились и домыслили свою версию, того что и как должно быть реализовано в целевом продукте. И так случилось, что эта версия не совпала с «комиксами» интерфейса пользователя, представленных заказчиком. Но делать нечего, QA специалисты люди суровые – есть несоответствие, получайте задачу на исправление.

    Когда разработчики исправили все замечания тестировщиков и передали версию для показа заказчику, изменения его сильно удивили и ошарашили. Он резонно заметил: «Я же этого не просил, откуда Вы это все взяли? Верните все как было назад», и в добавок, чтобы два раза не бегать, потребовал добавить еще кое-какой функционал. Пришлось убирать недавно реализованные возможности. И почти все переделать в связи с вновь открывшимися обстоятельствами.

    В это время менеджерам Компании «Доверие» пришлось доносить до руководства оперативную обстановку на фронтах, по проекту. Скрывать свою халатность и бездействие дальше было не с руки. Они и донесли: мол мы менеджеры белые и пушистые, а вот они — субподрядчики «косячники», ничего толком сделать не могут. Руководство в гневе собрало рабочее совещание и призвало субподрядчика к ответу: «Как же Вы допустили?». Когда выяснилось, что нет требований, и не просто нет достойного оформления по стандарту, который к слову существует в «Доверии», а нет вообще никаких требований, руководство очень удивилось и пожурило своих менеджеров. Те в свою очередь пытались оправдываться, парируя: мол какие-то материалы все же были предоставлены, все не так уж безнадежно и рано впадать в отчаяние. Признав свою недоработку, руководство «Доверия» клятвенно пообещало субподрядчику, что если только еще какие-то проблемы или недоработки со стороны менеджеров «Доверия» будут замечены, необходимо сразу звонить в колокола и бить в барабаны (или наоборот, в общем как получится). Негодяи тут же будут приструнены и сурово покараны. Вот она высшая справедливость, подумали в маленькой ИТ фирме. Есть же правда на земле!

    Когда реализовали следующий прототип с доработанными после первого показа возможностями, заказчик понял, что так работать, как он предполагал в начале, крайне неудобно, и нужно все переделать. А как? «А ПО ДРУГОМУ»!

    Тем временем, срок отведенный на проект закончился, а продукт, устраивающий заказчика так и не появился на свет. И тут заказчик проявил гуманность, вошел в нелегкое положение Компании «Доверие», согласившись продлить срок проекта еще на несколько месяцев. Естественно ничего не оплачивая. Соответственно команда субподрядчика не получила оговоренные по контракту средства и продолжила работать за свой счет.

    Шел 6- ой месяц проекта… При этом Компания «Доверие» особо ничего не теряла, ну продлили и продлили.

    Памятуя душевный разговор с руководством «Доверия» и его обещания навести порядок, субподрядчик обратились к нему с описанием нечеловеческих условий своего существования, без оплаты выполненных работ. И руководство откликнулось, клятвенно пообещав, что по факту обязательно оплатит всю переработку, но только потом, попозже, когда-нибудь. А менеджеры «Доверия» при этом продолжали настаивать, что субподрядчик исправляет свои же ошибки и должен делать это за свой счет. Все обещания наладить работу своего менеджмента руководство Компании «Доверие» начисто позабыло и переадресовало все претензии субподрядчика, как Вы думаете кому? Самому менеджменту. Они же свои, своих жалко. А субподрядчик что? Если сильный выплывет, а слабым — не место на рынке.

    И тут перед маленькой ИТ фирмой встал выбор: либо продолжить работать над проектом дальше и сохранить шанс – когда-нибудь вернуть оговоренные контрактом деньги, а возможно даже еще получить что-то за доработки, или бросить все и не получить по контракту, на который уже потратили 5 месяцев вообще ничего. А заодно и потерять своего заказчика в лице Компании «Доверие». Справедливости ради надо отметить, что небольшие суммы «Доверие» все-таки сбрасывал субподрядчику, исключительно, чтобы члены команда не убежали в другие фирмы. Выглядело это благородно, по меценатски.

    В результате, субподрядчик выбрал вариант – продолжать работу. Прикинули как можно реализовать необходимые в продукте функции, так чтобы пользоваться ими было удобно. Поменяли снова всю концепцию и переделали продукт еще раз. Снова потеряли изрядное количество времени.

    А в это время…, тестировщики Компании «Доверие», снова получили задание — как следует все оттестировать. Они калачи тертые и теперь уже не были столь самоуверенны в поисках подходящих материалов для составления тест кейсов. Обратились к разработчикам, для разъяснения: «А как же оно теперь должно работать?». Поскольку менеджеры Кампании «Доверие» никаких требований так и не удосужились разработать, то команде субподрядчика, пришлось подготовить документ о «Техническом решении», с описанием того, что и как реализовано в продукте на текущий момент. В результате тестировщики составляли тест кейсы не по требованиям, а фактически по тому как разработчики реализовали продукт. Оказалось бывает и такое.

    И вот субподрядчик выпустил очередной релиз продукта, точнее сказать ремикс на предыдущие версии и передал заказчику. Тот как обычно отказался от части своих прежних пожеланий, которые уже были реализованы. Но в общем-то, увиденное теперь уже не вызвало у него резкого отторжения.

    Маленькая ИТ фирма в очередной раз переделывает всякие мелочи в продукте и ждет, когда же этот ужас закончится…

    А может Компания «Доверие» предложит новый проект?
    «И ждём недождёмся,
    Когда же ты снова пришлёшь
    К нашему ужину Дюжину
    Новых и сладких калош!»
    Корней Чуковский.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 49
    • +1
      Спасибо, на Вашем примере я снова наматываю на ус, что нельзя (нежелательно) работать без четкого видения конечного продукта
      • +9
        Можно, но с почасовой оплатой. И тогда резину можно тянуть до бесконечности.
        • 0

          Можно припрямом контакте с хорошо и давно известном тебе заказчиком. С теми же самыми людьми если, с коими работаешь уже годы — можно рискнуть

        • 0
          Еще очень важно чтобы видение конечного продукта совпадало у заказчика и исполнителя. При наличие посредника, появляется третье лицо и все еще усложняется.
        • +2
          К сожалению, в наших реалиях существует и еще более худший вариант, когда фирма «Доверие» — это не крупная IT компания, а «рога и копыта», но с личными или родственными связями с руководством заказчика.
          • 0
            Согласен, сталкивались с этим. Причем бывает смешно… От заказчика бюджет 1 000 000, а уже Рога и копыта ищут кто за 100 000 сделает, и причем как в истории, все косяки и доделки за их счет.
          • +7
            «… мы сейчас только свистнем и к нам прибегут команды и выстроятся в очередь…» — компания явно говорит Вам «мы идиоты, бегите от нас быстрее»
            • 0
              Если бы кругом было полно работы по нашему профилю, и к нам стояла очередь, за тем чтобы купить у нас работу, мы — «идиоты» наверное и не связывались бы с «Доверием».
              • 0

                Это было про компанию «доверие», но в целом то понятно что Вы больше заинтересованы в «доверии», чем наоборот, чем они и пользуются.

            • –1
              Спасибо за статью!

              Касательно литературной части:
              все не так уж безнадежно
              Должно быть либо «все не так уж безнадежны», либо «всё не так уж безнадежно».
              Процитированный Вам Корней Чуковский, например, букву Ё не принижает ;)
              • 0
                85% совпадений с нашим проектом. Спасибо за то, что не поленились описать ситуацию.
                А не хочешь так работать, мы сейчас только свистнем и к нам прибегут команды и выстроятся в очередь

                Тут боль всех небольших разработчиков.
                • +1
                  Есть простое правило. Не работать на субподряде.
                  • +1
                    В современной России, к сожалению, для небольшой компании субподряд — это зачастую единственная возможность получить заказ.
                    • 0

                      Фиксируйте убытки и закрывайте контору в таком случае.

                      • 0
                        Странное предложение. Из-за одного или нескольких таких проектов контору не закрывают, ибо другие проекты помогают выбраться из подобного.
                        • 0
                          Вы же сами сказали «единственный». А теперь, внезапно, появился выбор. Выбирайте более маржинальные проекты, отказывайтесь от кабалы, в чем беда?
                          • 0

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

                            • 0
                              Уже много раз наблюдаю в чатах картину, когда разработчики пытаются давать советы менеджерам, как правильно организовывать работу, найти деньги и т.д. Тут надо или попробовать поработать самому менеджером и поискать заказы, деньги и т.д., либо суметь посмотреть на проблему с другой точки зрения, четко осознавая все входные параметры.
                              • 0
                                С менеджерами проблема одна, они (за редким исключением) не могут говорить «нет» заказчику. В результате имеем нечеткие ТЗ, срыв сроков и т.д.
                                • 0
                                  Какой профснобский ответ)
                                  Ну, заморозьте комментарии под статьёй-о-проблемах-продаж на ресурсе для разработчиков, что ли… или на хабре врубать Сашуспилберг (обожаю красавицу!) нельзя?
                                  Разрабы должны молча проникаться?

                                  Давайте так. Как давно «Доверие» было размером с вас? Ключ успеха был в знакомствах продажников?
                                  А программерам побыть манагерами Вы предлагаете — где? У себя или там?
                                  Ладно, не будем обострять.

                                  А если мыслить по схеме «проблема-решение», то… У нас тут рыночное равновесие в неоптимальной точке… я бы закон предложил, запрещающий субподряд без контакта заказчика с конечным исполнителем. Если заказчик слишком важный и государственный, чтобы дёргать по телефонам — значит, обеспечьте участие в совещаниях и право инициировать совещания. Если «Доверие» видит здесь свой репутационный ущерб — либо пусть субподрядчик представляется красивым именем «Доверие» (придумайте, как! Код-то вы в комментариях как подписываете, чьим именем? Блин, спалился, что я не настоящий программист, а 1Сник; у нас ничего не компилится), либо можно вообще придумать форму трудовых отношений, чтобы субподрядчики действительно регистрировались в «Доверии», и можно было бы на совещаниях/на звонках представляться так без обмана. Одно замечание сходу: любая форма доступа к драгоценному Телу должна оформляться начиная с уровня рядовых сотрудников, чтобы не было потом «на директора был выписан талон, а раз он не позвонил...». Дисциплинарные вопросы, типа, не отвлекать сотрудников Заказчика по пустякам, фирма-субподрядчик вполне умеет решать внутри себя. Не отвлекать — значит, не допускать срыва контракта из-за проблем такого рода. И эта ответственность субподрядчика должна быть продумана в таком законе.
                                  Что Вы обо всём этом думаете?
                                  • 0
                                    Мне тут забавно наблюдать, будучи бывшим владельцем и нынешним совладельцем аналогичной конторы. Факт в том, что любой человек, так или иначе продает свои услуги и считает выгоду. Непонимание и снобизм в таких вопросах лишь показывает, что ребятам дали правильный урок на этом проекте. Выучат они его или нет это другой вопрос.

                                    P.S. поддерживаю идею законодательных запретов передачи на субподряд, т.к. происходит натуральное мошенничество. Необходимо законодательно прописать передачу 25% государственных it бюджетов микрокомпаниям.
                                    • 0
                                      Необходимо законодательно прописать передачу 25% государственных it бюджетов микрокомпаниям.

                                      Нафиг-нафиг, простите меня пожалуйста.
                                      Во-первых, по тем же причинам, по которым предложение N. освободить малый бизнес от налогов совсем — небезобидная демагогия. (это утверждение — никакая не политика, раз уж мы договорились без политики, и не требует от меня объяснять, почему N. должен сидеть, и… молчу-молчу)
                                      Во-вторых, если для обеспечения госзаказа нужно вырасти — почему же микрокомпания не хочет вырасти? Например, до 100 сотрудников? Или до покупки дырокола? Не получается управлять масштабами, а налогоплательщики — оплачивай? Простите, тут масштабы.
                                      • 0
                                        Вы пробовали микрокомпанией выйти на тендер гос.заказа? Это не реально, только если заказ уже совсем нежизнеспособный. В том-то и дело, что участие в тендерах — это отдельный бизнес, и позволить себе им заниматься микрокомпания вряд ли сможет. Причем в крупных фирмах это отдельное направление — выигрывание тендеров, отдельное от реализации этих тендеров.
                                        • 0
                                          Поддержка малого бизнеса гос. контрактами это возможность дать им жить и бодаться, а не бегать по рынку с голодными глазами, дать возможность быть на равных и в случае притеснений писать не в дорогой дневничекна хабр, а в суд. Когда они перестанут быть голодными оборванцами, самые амбициозные решат, стоит им бороться за крупные куски или нет.

                                          Вместе с тем налогоплательщики оплачивают сейчас весь этот цирк и их никто не спрашивает. Я предлагаю внести коррективы в текущее законодательство и сбалансировать систему, которая законодательно позволяет прописать «компания должна иметь оборот 120 000 000 рублей за последний год» в тендере на поддержку муниципального сайта.
                                          • 0
                                            Когда они перестанут быть голодными оборванцами — то с удивлением обнаружат, что стали средними компаниями. )

                                            120 000 000 рублей — ух ты, это <=10 разрабов, что ли?
                                            Границы фирмы определяются жизнеспособностью её модели.
                                            • 0
                                              ой… в 10 раз ошибся, по цифрам.
                                              <= 100 сотрудников, конечно же.
                                              Да давайте уж сразу — подрядчик должен быть на УСНке… чтобы не дублировать всякие формы отчётности и тендерной документации.
                                              • 0
                                                Жизнеспособность модели определяется внешней средой. Да я предлагаю убрать отсечку компаний, в которых трудятся < 10 разработчиков, в чем проблема?
                                                • 0
                                                  Видимо, во внешней среде?
                                                  • 0
                                                    И я так думаю
                                        • 0
                                          Ну выскажусь после такого длинного и глубокого комментария…
                                          Вопрос в том, что большие фирмы, имея репутацию, сейлов, тендерные комитеты и т.д. могут себе позволить участвовать в тендерах и выигрывать их. А дальше можно снять сливки: самые «жирные» проекты оставить себе, а остальное слить субподрядчикам. По описанной в статье схеме.
                                          Но тут возникает проблема, что эти самые менеджеры «Доверия» начинают халтурить не только с субподрядчиками, но и в проектах, ведомых самим «Доверием». Это становится конвейером, в котором халтура становится нормой.
                                          Хотелось именно это донести до всех «Доверий». Если они не начнут меняться, проблемы будут у всех: и у Больших и у Маленьких!
                                          • 0
                                            Тогда статья неправильно заканчивается. )
                                            • 0
                                              А она не заканчивается. Она приостанавливается.
                                      • 0
                                        В моем мире разработка софта является довольно старым и понятным бизнесом со своими критериями маржинальности. А в вашем мире герои лихо на повороте обскакивают ООО «Доверие» и выходят в лидеры рынка. Какой из них верный я не берусь судить, просто предлагаю к вашим услугам собственный опыт
                                        • 0

                                          Пожалуйста, расскажите нам критерии маржинальной и на примере этого проекта.

                                          • 0
                                            Хорошая попытка, но зачем вам это?
                                • 0
                                  Почему невозможно в России напрямую? За 16 лет работал на субподряде всего 2 раза.

                                  Если ты хочешь работать с госзаказом — просто выясни специфику этого.
                                  Ну а с коммерческими — проблем нет
                              • 0
                                После того, как заказчик согласился на продление сроков, субподрядчику надо было приостановить все работы до полной оплаты контракта, потому что обещанные 4-5 месяцев уже прошли, куча работы сделана, и компании Доверие гораздо дешевле было бы заплатить за работу, чем получать претензии от заказчика, потому что у них уже не было времени на поиск других субподрядчиков.
                                • +1
                                  Несколько непреложных принципов:
                                  1. Предоплата 30-50% для fixed bid проектов. Без предоплаты — не работаем.
                                  2. Четкая фиксация требований. Требования могут быть нечеткими, но фиксация — обязана быть.
                                  3. Никаких устных уточненных требований и договоренностей. На все сказанное устно (без записи разговора) — получать подтверждение в электронном или письменном виде.
                                  4. Планирование рисков. Нужно иметь на руках план «б» на случай изменений требований, неоплаты во-время, и других форсмажоров.
                                  5. Когда случаются крупные риски, в виде совершенно неверно сформулированных требований или чего-то подобного, приостанавливать связанную с этим работу до момента, когда риск разрулен. Это хорошо стимулирует клиента быстрей и четче решать вопросы на своей стороне.
                                  • 0
                                    Хорошие принципы!
                                    А из каких средств платите з\п пока нет подходящих клиентов, которые готовы работать на Ваших, а не своих условиях? Просто сидите без работы и ждете, пока появится «вкусный» клиент?
                                    • 0

                                      Из моих 5 пунктов только первый потенциально отсеивает клиентов, которые не платят предоплату. С новым интересным клиентом всегда можно попробовать договориться, скажем не о предоплате сразу, а после первого прототипа, где то через месяц. Адекватный заказчик на такое согласится. А с неадекватными, которые не платят, не надо работать вовсе.

                                  • 0
                                    Описанная проблема — это из разряда задач менеджмента. Формализация задач и требований — это не просто прихоть. Это форма выживания малых контор. Практически всегда из-за отсутствия формализированных требований возникает целый скоп задач, которые придется делать бесплатно.
                                    У нас неоднократно были ситуации, когда именно записи в jira, e-mail, прочие документы (в которых мы согласовывали требования (точнее, даже пожелания, которые мы сами трансформировали в требования)) спасали нас в спорах, связанных с финансированием выполняемых работ.
                                    • 0
                                      image
                                      • 0
                                        Классическая история под названием «Не умеем продавать» в редакции «полный фарш». Формируйте компетенции «активные продажи», «переговоры» и «управление клиентом». Бог и SPO-агентства вам в помощь. И конечно удачи!
                                        • 0
                                          Хороший сейл стоит под стать среднему программисту. Если штат 10 программистов, как этого сейла кормить? Он не окупится. А резко перейти на 50-100 программистов как-то не получается. Спасибо за ценный совет: «Формируйте компетенции «активные продажи»». Ура товарищи, ударим автопробегом по бездорожью!!!
                                          • 0
                                            Задумайтесь на минутку. Как в принципе может не окупиться сейл, если он своей работой окупает всех программистов? Эта ментальная ловушка давно знакома экспертам, которые помогают ИТ-компаниям: мол, сейл — лишний пассажир и вообще непонятное животное. То ли дело лишний бэкэнд программист или хотя бы тестер. А истина в том, что продавать должен либо руководитель, либо сейл, и эти двое окупаются в первую очередь, если конечно что-то приносят. Сейл — центр прибыли, продакшен — центр затрат.
                                            • 0
                                              Как в принципе может не окупиться сейл, если он своей работой окупает всех программистов?

                                              Это закон такой такой есть?
                                              Сеил может окупаться, если фирма имеет свой продукт, который необходимо продавать. Продавать просто ресурсы на аутсорсинг думаю сейлу не с руки.
                                              А чтобы создать свой продукт, который можно продать, нужен инвестор и затея самого продукта. Либо время, чтобы в фоне проектов, приносящих какой-то доход на содержание фирмы можно было разработать маркетинговый продукт. Но по факту этого времени не хватает.
                                              • 0
                                                Продажа услуг заказной разработки, аутсорсинга для компании «Доверие», консалтинга — все это продажа. В описанной сделке, на мой взгляд, был допущен ряд классических ошибок на цикле продажи: 1. начата работа без договора, потому что 2. не было снято возражение «таких как вы миллион», 3. перед работой не были качественно выявлены потребности, из чего вылилась масса переработок, 4. в ходе работы не осуществлялось управление ожиданиями клиента, не снимались возражения, так как не снят п. 2. Я конечно не истина в последней инстанции, но поскольку занимаюсь увеличением продаж именно ИТ-компаний, как минимум богатый опыт имею.
                                                • 0
                                                  Там же в статье написано -договор заключен, но договор с кучей страховок для подрядчика и без прав для субподрядчика. Все остальное действительно было. Но когда команде надо платить каждый месяц зарплату, а других работ нету, то идешь на риски, тем более, что до этого с Доверием работали много лет и таких проблем не было. Про «управление ожиданиями клиента», там же опять таки написано, что доступа к клиенту у субподрядчика не было. Там в статье про все это написано. Вы пытаетесь давать оценку не той ситуации, которая описана, а как в кейсе из учебника по среднестатистической задаче. У меня есть образование MBA, я все это изучал. К сожалению в нашей стране не все работает так как написано в учебниках.
                                                  • 0
                                                    Не обижайтесь на меня и не расстраивайтесь :-) Я всего лишь пытаюсь сказать что-то, что поможет Вам задуматься и избежать таких ситуаций в будущем.

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