SVK

+1
с 2020

Заказная разработка продуктов-победителей! Внедрение PIM, разработка ERP, интернет-магазинов, MVP https://www.internet-design.ru/

25 подписчиков
27 подписок

Да тут дело-то не столько в T&M, сколько в принципе получается предложение взять на себя чужие риски с довольно жесткими сроками.

Ну и, что греха таить - T&M на рынке всё ещё довольно плохо продается новому заказчику. Когда за плечами есть 3-6 месяцев сотрудничества - да, конечно же - только T&M. Но первый контракт по нашим наблюдениям довольно тяжело продать в режиме T&M. Чаще это всё-таки FP.

Тестировщики, кодеры и другие спецы как раз включаются в статью затрат на разработку. Там же еще и аналитики и UX/UI-проектировщики, и т.д. То есть конечно же 800 человек — это не только одни лишь программисты.

В остальном все так, как Антон Кузьмин уже ответил. В крупных проектах речь идет не об одном только сайте. Даже сам сайт — это жуткий муравейник из множества сервисов (витрина, админ.часть, PIM-система, OMS-система, Логистика и склад, и т.д. и т.п.), а ведь есть еще мобильные приложения (часто — нативные, а значит две небольшие команды разработки, как минимум), зачастую есть несколько продуктовых направлений (у того же Авито активно развивается и сервис в стиле YouDo и "работный" сервис и т.д.). Ну и конечно же многочисленные сервисы внутренней автоматизации.

Каждый такой сервис часто обслуживает "небольшая" команда из 10-20 специалистов. Так что 700 человек получается — это "всего" около 35-45 таких сервисов. Что для большого проекта, в общем-то не так уж и много.

1

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

Ну, к ребятам из SVK обратиться — это само-собой ))

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

Это делает экономику посягательств на фреймворки менее интересной. Это, как минимум.

Александр, здравствуйте! Извините за неудобство. Это произошло, потому что были цифры в названии организации. Уже исправили эту ошибку. Попробуйте еще раз, пожалуйста, либо отправьте запрос на email: info@internet-design.ru (email и телефон указаны слева от контактной формы под заголовком).

Вячеслав, думаете его все-таки нужно было добавить на сайт? :D

Спасибо за ваше замечание! Учтем в следующих наших проектах этот нюанс. Наша специализация - это все-таки веб-разработка и веб-дизайн, в этом мы хороши)

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

Цифровизация и передовой маркетинг придут в российский спорт вместе с деньгами. Если посмотреть структуру доходов российских и зарубежных клубов - доля доходов от продажи билетов и атрибутики в них, к сожалению, будет отличаться, зачастую, на порядок.

1

Парсеры типа KeyCollector или СЕО-шные сервисы, но все они данные из того же Wordstat берут

Спасибо за отзыв и поддержку! В большом лонгриде (цель которого - максимально облегчить жизнь опытным пиарщикам и копирайтерам, но без опыта в айти) есть и про то, что у менеджера проекта нужно узнать состав команды, и опросить каждого. Создание кейса - это действительно проект, спасибо!

Alex, привет! Да, это действительно лонг-лонг-рид, в котором что-то можно было пропустить) Создавался как аккумуляция личного опыта для коллег в похожей ситуации)

Кейсы в отрасли часто собирают пиарщики, не PR-директора. И заниматься текстами часто приходят копирайтеры или пиарщики не напрямую из отрасли разработки. Я обращалась к нескольким крупным компаниям - ситуация везде похожая.

Но бывает и круто - когда менеджер проекта сам хорошо пишет и структурирует.

В моём случае история именно про отсутствие платформы для работы копирайтера (ребята просто классно делали свою работу, пиар не строили, редполитику не составляли), которую мы на первом кейсе хорошо прочувствовали и обкатали.

Первый кейс собирался долго, 2 месяца (от и до). После создания "земли" для опоры новые кейсы я собираю быстрее, за 2 недели (включая упаковку в иллюстрации и сборку на сайте). Но если у дизайнеров полная загрузка по клиентским задачам, тогда дольше, жду очереди.)

А где именно триггернуло? - Мне интересно)

Но как рассказать историю, не умея рассказывать? :) Если умеешь рассказывать, узнай историю у специалистов, уточни детали и расскажи) Текст об этом)

Мария, здравствуйте. Никаких ограничений по шопинг-тегам у нас не было. Последняя публикация с их использованием у нас была 30 мая, всё работает. 

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

Просто за период карантина этот вопрос начал в разы чаще звучать. Видимо, люди считают, что с таким документом лучше контролировать итоговые договоренности при удаленной работе. А мы вот не согласны :)

Поэтому и решили пост, наконец, написать: о своем подходе рассказать, других послушать.

1

T&M, как и ФФФ, во многих случаях действительно являются оптимальными вариантами реализации сложных проектов, выгодными как подрядчику, так и заказчику.

Но здесь вылезает проблема из другой плоскости: большинство российских клиентов не готовы по ним работать, в отличии от европейских и американских заказчиков. У нас, по крайней мере, очень редко получается сходу договориться о T&M с российскими компаниями. Сначала приходится жить с полностью зафиксированными договоренностями, нарабатывать определенный уровень доверия, и тогда уже T&M начинает хорошо работать.

User Story да, пока не добавили в обязательном порядке, но иногда используем, когда в проекте много ролей и сценариев и при последовательном описании получаются нечитаемые "портянки".