Средний бизнес (СБ) — характеризуется монолитной инфраструктурой (работы по развитию инфраструктуры в компании не постоянны, а по потребностям). Также в среднем бизнесе присутствует понимание рынка заказной разработки, но отсутствует углубленная техническая экспертиза (топ-менеджмент с опытом, но без штата специалистов имеющих углубленные понимания процессов реализации проекта).

Крупный бизнес (КБ) — характеризуется постоянно развивающейся инфраструктурой и наличием профильной экспертизы внутри компании и распределенной по отделам ролевой моделью.

Стартапы (С) - нередко характеризуются наличием углубленной технической экспертизы, но отсутствием инфраструктуры (оно и понятно, поскольку они чаще всего приходят с деньгами за развитием инфраструктуры и созданием технологического решения).

Хочу обозначить два момента:

1. Под экспертизой подразумевается совокупность софт-скилов и технических компетенций

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

В данном перечне отсутствуют типы заказчиков, которых я больше отношу к частным случаям будь то:

1. Заказчики, желающие сотрудничества по разработке продукта, не имея бюджета (просящие в долг).

2. Госкорпорации и государственный сегмент.

3. Крупные компании, самостоятельно работающие с исполнителями по модели аутстаффинга.
   

Виды исполнителей

Небольшое отступление, бус-фактор (Bus factor) — это параметр, определяющий сколько человек должен потерять исполнитель, чтобы проект не имел возможности и смысла дальнейшей реализации с данным исполнителем. Чем данный параметр выше, тем лучше.

Фрилансеры (Ф) — характеризуются формой организации (чаще всего это самозанятые, либо ИП) и уровнем компетенций, который определим как средний, поскольку рынок перенасыщен низкоквалифицированными кадрами, а высоко компетентные специалисты уходят в найм, либо развиваются в открытие своего собственного дела.
Ролевая модель проекта закрывается только посредством кросс-функциональности отдельных специалистов. Самый низкий бус-фактор среди всех исполнителей.

Лоукостеры (Л) — характеризуются отсутствием экспертизы у подавляющего числа специалистов в компании, и в то же время очень хорошими компетенциями в сопровождении клиентов, и в продажах. Ролевая модель закрывается отдельными специалистами, но при этом узкопрофильные эксперты отсутствуют.
Бус-фактор максимально высокий из всех видов исполнителей на рынке.

Бутик (Б) — характеризуется высокой экспертизой у всех участников реализации проекта, но при этом ограниченным объемом ресурсов. Ролевая модель закрывается отдельными экспертами, но присутствуют случаи частичного сопряжения ролей.
Бус-фактор низкий.

Фабрика (ФБ) — характеризуется уменьшением экспертизы (в сравнении с бутиком) за счет размытия компетенций при увеличении штата.
Кросс-распределение обязанностей отсутствует.
Бус-фактор высокий.

Гибридный Бодишоп (БШ) — характеризуется очень большим объемом доступных ресурсов и системой обособленности команд разработки. Бус-фактор компании выше чем у фабрики, но для отдельно взятой команды ниже. При этом компетенции аналогичного уровня, что и у фабрики.

Небольшая ремарка относительно «гибридного бодишопа». Бодишоп — это компании работающие по модели аутстаффинга. В России это не так распространено как на западе. У нас крупные компании такого формата позиционируют себя как разработчики проектов на заказ, предлагающие аутстаффную модель сотрудничества.

Мы определили виды заказчиков и исполнителей

Типы технического задания

Теперь перейдем к классификации типов технического задания.

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

1. Необходимое для формирования юридических рамок (Юридическое ТЗ).

2. Включающее предыдущее и достаточное для определения конечной формы реализуемого проекта (Полное ТЗ).

Юридический вариант ТЗ имеет один неоспоримый плюс, можно быстро приступить к работе и углубиться в сотрудничество.

Первый тип ТЗ можно описать двумя крайними видами:

1. Жесткое (шаг влево, шаг вправо — допы): такая форма применяется у лоукостеров и фабрик с готовыми решениями. Они работают с определенной аудиторией заказчиков для которой реализация проекта идет рука об руку с экономией. Поскольку такие проекты очень сильно похожи друг на друга, то у исполнителей уже есть шаблон ТЗ в который необходимо вписать пожелания заказчика, а функциональность, используемая при реализации проекта, будет типовой.

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

Теперь рассмотрим второй тип — Полное ТЗ, которое дает ярко выраженное представление для всех сторон о конечном результате.

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

Обозначим данные два вида технического задания как строгое и творческое:

1. Строгое техническое задание подходит для всех исполнителей, для которых проект является просто возможностью увеличения нагрузки на компанию. И это очень хорошо для определенного вида проектов, и для заказчика, у которого есть хорошая техническая экспертиза. Эффективнее всего такое техническое задание для работы с фрилансерами, фабриками и гибридными бодишопами.
   Для лоукостеров это приемлемый вариант, поскольку они могут позволить себе увеличение объемов работы для компенсации неточности реализации, при этом не выходя за рамки бюджета, что они спокойно делают за счет финансовой модели реализации проектов. Для бутиковых компаний такое ТЗ накладывает ограничения, в связи с которыми они теряют свое основное конкурентное преимущество - влиять своей экспертизой на проект.

2. Творческое техническое задание — это форма, в которой у опытной команды есть возможность реализовать весь свой потенциал и полноценно внести в проект свою экспертизу.
   При таком формате у заказчика есть возможность апеллировать ТЗ при определении уровня качества реализации, а у команды появляется ответственность провести согласование всех творческих решений и реализовать проект с обозначенным путем реализации.
   Такое ТЗ подойдет для сотрудничества с фрилансерами, бутик-компаниями и фабриками.
   При работе с гибридным бодишопом возникнут вопросы по отношению к качеству креатива полученного от такой компании: заказчик получит высокий уровень качества реализации кода, но визуальная составляющая будет определяться специализацией исполнителя и может быть ситуация, при которой у конечного исполнителя, работающего с проектом, не будет опыта работы с нишей заказчика.
   Для лоукостеров такое ТЗ как точка роста, если у исполнителя есть выделенная команда для таких проектов. В противном случае заказчик может не получить того уровня качества, которое ожидает.

Обобщим: есть 4 вида заказчиков, есть 5 видов исполнителей и 4 вида технического задания.

Как определить какое техническое задание необходимо для проекта

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

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

В случае если денег нет совсем, то можно работать с лоукостерами или фрилансерами. С кем именно работать - лучше определиться, основываясь на наличии экспертизы со стороны заказчика.

• Если заказчик понимает как устроены все процессы реализации проекта и может ими управлять, то лучше к реализации проекта привлечь фрилансеров.

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

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

При этом надо понимать о каких цифрах идет речь в вопросе выделения бюджета на техническое задание.

Юридическое ТЗ можно реализовать без бюджета. В таком формате в первую очередь заинтересован исполнитель, который готов работать с бюджетом заказчика.

В случае, если мы говорим о крупном проекте стоимостью от нескольких миллионов рублей, то я рекомендую выделять около 10% доступного бюджета на написание ТЗ. Чем объемнее проект в трудозатратах, тем больше должно быть проведено подготовительной работы, начиная с текстового описания и заканчивая маркетинговыми исследованиями и разработкой прототипов.

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

Если заказчик не может это сделать самостоятельно, есть два варианта:

1. Доверить данную задачу консалтеру, который может в последствии на себя взять работы по управлению проектом со стороны заказчика.

   2. Доверить написание технического задания исполнителю, которого заказчик выбрал для дальнейшей реализации проекта.
   

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

   1. Не работать с лоукостерами. Основа работы с ними в их подходе к рынку: они не накапливают экспертизу для реализации крупных проектов (все банально - чем больше сотрудник иполнителя понимает и умеет, тем дороже он стоит для исполнителя, что в свою очередь влияет на стоимость реализации проекта для заказчика: им невыгодно накапливать такую экспертизу для работы с крупным бюджетом в случае, если они работают в сегменте небольших лоукост проектов).

2. Заказчик может попробовать самостоятельно собрать команду для своего проекта  если внутри есть управленческая и техническая экспертиза, и заказчик имеет время для поиска и формирования команды. Плюс такого подхода в некоторых формах владения интеллектуальной и авторской собственностью разрабатываемого проекта, в том что заказчик может за меньшие деньги получить намного больше трудоресурсов для своего проекта, но вместе с тем он берет на себя все риски по реализации проекта, простою сотрудников. При этом, ему надо прогнозировать какой рентабельной нагрузкой он обеспечит сотрудников по завершению проекта. Минус такого подхода в том, что экономия такого характера не всегда выгодна (пример: выплачивая специалисту на руки зарплату в 120 тысяч, заказчик сверху еще платит 59 тысяч налогов, и в итоге, в годовом обороте это 2 330 000 расходов), а заказчик при этом имеет доступ к экспертизе только внутренних сотрудников.

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

У нас остается три варианта не учтенных исполнителей для реализации крупного нестандартного проекта:

1. Работа с бутиковой компанией имеет свой риск ввиду ограниченности ресурсов исполнителей для проекта. Чтобы это нивелировать необходимо максимально спрогнозировать потенциальные точки расширения со стороны заказчика, поскольку в случае, если это не будет учтено, то проект может выйти из под контроля (так бывает часто, поскольку в ходе реализации у заказчика просыпается аппетит, а формат бутика в том, что там нравится подход к работе, и сложно остановиться, когда у компании при этом есть бюджет. Но правда такова, что бутик не может уйти в работу с одним заказчиком на годы, и не может поставлять высококвалифицированные кадры, забирая их с рынка (формат компании не такой)).
   

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

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

Подведем итоги:

Когда необходимо написание полноценного технического задания:

• когда на стороне заказчика нет компетенций по реализации проекта .

• когда заказчик выделяет большой бюджет на проект.

• когда в проекте не предполагается интенсивного участия заказчика в ходе реализации проекта.

Когда можно использовать юридическое ТЗ:

• когда между заказчиком и исполнителем уже выстроены  взаимоотношения и обе стороны имеют положительный опыт работы друг с другом.

• когда разрабатывается типовой проект.

И техническое задание не нужно:

• когда со стороны заказчика присутствуют высокие компетенции и ресурсы на сопровождение реализации проекта.

• когда заказчик формирует внутреннюю команду разработки, где надо выстраивать процесс и писать спецификацию, а не ТЗ.

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

Ну и по традиции пикабу, что бы меня было за что хейтить), выкладываю ссылку на телеграм канал https://t.me/skillline_ru. Там я опубликовал подкаст по данной теме.

И бонусом: если у вас есть техническое задание, и вам нужно проконсультироваться, я готов вам бесплатно помочь (под помощью подразумевается: вычитать ваше ТЗ, определить его слабые и сильные стороны, ответить на ваши вопросы). Для этого пишите в телеграмм @EKovalevich

!(4) и что-то новенькое: hh.ru, на котором размещаются резюме, начал проверять точность информации и связываться с работодателями.

Поэтому поговорим о том, как можно привлечь внимание к себе, чтобы потом не уволили, как в этом случае:

(1) Начинать искать как можно раньше (когда изучена уже какая-то база), потому что то, что дают на курсах не всегда равно требованиям компаний. Чем больше смотрите вакансии и общаетесь, тем лучше понимаете, что нужно рынку.

(2) Использовать нетворкинг - знакомиться с людьми, которые работают в тех компаниях, куда вы хотите. Даже просто написать и попросить зарефералить. Теория с рукопожатиями тоже работает (у меня так много клиентов и знакомых нашли работу)

*кстати, консультант тут тоже обычно помогает и закидывает резюме по своим каналам (это, конечно, не гарантия успеха, но повышает конверсию)

(3) Резюме должно быть продумано до мелочей, из самого базового:

➡️ название должности должно соответствовать названиям вакансий, т.е не "специалист", а максимально конкретно;

➡️на первом месте должен быть опыт по той вакансии, на которую вы хотите, даже если это учебный опыт;

➡️ расписать подробно навыки, которые вы получили на обучении, лучше сразу с примерами из практики.

(4) Брать из предыдущего опыта все навыки, которые могут быть полезны. Смена направления — это не начинать с нуля, всегда есть переносимые навыки. Например, опыт ведения коммуникации и работа в команде, который есть у всех, и другие soft skills. Успех поиска 50/50 зависит от hard и soft skills.

(5) Использовать сопроводительные письма и писать вдумчивые отклики на позиции (спам-рассылка скорее всего не даст результата). А вот резюме + нормальное сопроводительное можно отправлять не только на hh, но и напрямую в компании, даже если вакансии нет, вас могут добавить в базу и написать позже.

*я всегда читаю, когда вижу, что человек постарался, а иногда даже даю обратную связь и помогаю скорректировать.

(6) Использовать разные источники поиска, в том числе рассматривать стажировки, после которых можно трудоустроиться (иногда это быстрее, чем искать вакансии).

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

main: (0001, 0002, 0003)
replica: (0001, 0002)

Если основной узел выйдет из строя, то дальше все операции по записям возьмет на себя реплика. В указанном случае она будет выдавать идентификаторы далее: 0003, 0004, ... . Получается, у разных узлов будет разное представление об операции с id = 0003 - это создаст конфликт, если первый узел вернется к жизни.

Можно было бы вместо этого выбирать тысячную запись не по id, а по времени создания. В этом случае можно использовать UUID как идентификатор, и добавлять время создания записи, чтобы позже по нему выявить 1000-го пользователя. В случае падения основного узла конфликта с id не будет, но на разных узлах может не совпадать время - а это бывает при проблемах с ntp сервисами. Например, во время выхода из строя основного узла время на нем было 15:20, а на реплике 15:12, и у новых пользователей время будет меньше чем у существующих.

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

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

🚀 Присоединяйтесь к Революции в Мире Шопинга с Нашим Новым Приложением!

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

🌍 Мы представляем революционное приложение, которое изменит ваш опыт покупок навсегда! Это приложение – ваш личный помощник в расчёте стоимости товара за килограмм. Проще говоря, оно поможет вам делать осознанные и экономически выгодные выборы, не тратя лишнее время и силы на расчёты.

✨ Как это работает?

• Простота использования: Введите цену продукта и его вес – приложение мгновенно выдаст цену за килограмм.

• Экономия времени: Забудьте о сложных подсчётах в магазине. Теперь все расчеты сделает приложение за вас.

• Лучшие решения: Сравнивайте цены на разные продукты и выбирайте самые выгодные предложения.

• Образовательный аспект: Улучшайте свои навыки в финансовом планировании и бюджетировании.

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

💪 Присоединяйтесь к нам и станьте частью решения! Вместе мы сделаем покупки проще, умнее и выгоднее для всех!

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

Техническое задание на создание мобильного приложения "PricePerKilo"

1. Введение

Цель этого документа - описать требования к разработке мобильного приложения "PricePerKilo". Это приложение предназначено для вычисления стоимости продуктов за килограмм по данным, полученным с камеры смартфона.

2. Описание приложения

2.1. Функциональные требования

1. Распознавание данных с фотографии: Приложение должно распознавать цену и вес продукта с фотографии, сделанной камерой смартфона.

2. Ручной выбор данных: Пользователь должен иметь возможность вручную выделить на фотографии цену за упаковку и вес в граммах.

3. Вычисление стоимости за килограмм: На основе полученных данных приложение должно автоматически вычислять стоимость продукта за 1 килограмм.

4. Сохранение результатов: Результаты вычислений должны сохраняться в памяти устройства.

5. Сравнение цен: Пользователь должен иметь возможность сравнивать сохраненные данные по разным продуктам.

2.2. Нефункциональные требования

1. Интерфейс: Интуитивно понятный и удобный интерфейс.

2. Отсутствие рекламы: Приложение должно быть свободно от рекламы.

3. Автономность: Приложение должно работать без доступа к интернету.

4. Безопасность: Защита личных данных пользователя и сохраненной информации.

3. Технические требования

3.1. Распознавание изображений

• Использование библиотеки для распознавания текста на изображениях (например, Tesseract OCR).

• Алгоритмы для выделения и распознавания числовых данных на фото.

3.2. Платформы

• iOS и Android.

3.3. Язык программирования

• Рекомендуется Kotlin для Android и Swift для iOS.

3.4. Локальное хранилище данных

• SQLite или аналогичная система для хранения результатов расчетов.

4. Дизайн и пользовательский интерфейс

• Современный и минималистичный дизайн.

• Удобная навигация по приложению.

• Визуальное выделение выбранных данных на фотографии (цена, вес).

5. Тестирование

• Модульное тестирование основных функций приложения.

• Интеграционное тестирование для проверки взаимодействия различных компонентов приложения.

• Функциональное тестирование интерфейса пользователя.

6. Заключение

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