Уложиться в срок
Когда РП заставляет аналитика закончить работу над ТЗ в срок...
Когда РП заставляет аналитика закончить работу над ТЗ в срок...
Решила наша организация закупить УАЗ Патриот для служебных нужд, написали соответствующие письмо в контрактную службу, на что нам ответили: "пишите ТЗ", доверили такую ответственную задачу нашему водителю, ну он и написал: "надо что бы ехал, и привод полный и печка грела"...в итоге мы имеем полноприводный УАЗик в комплектации "бомж с печкой"... Мультимедия отсутствует, всевозможные подогрева отсутствуют, из всех кнопок доступна только аварийка и ещё одна непонятная, зато есть климат и полный привод) На наши вопросы ответ был прост, нет в тз, нет в машине, спасибо, что хоть двери были)
тщательно продумывайте каждую мелочь в техническом задании и не перекладывайте ответственные задачи на неопытных людей, самое смешное, что под ТЗ водителя подписалось куча начальников, но виноватым называют его...
Получился очень длинный пост. Чукча не писатель, так что перейдем к сути дела. Тапками кидайте: конструктивную критику воспринимаю хорошо.
Для ЛЛ: Хорошее ТЗ это хорошо, можно с простым ТЗ, можно без ТЗ. Важно уметь договариваться.
Всем привет. Меня зовут Евгений Ковалевич. Я генеральный директор компании Skillline.
Мы запускаем циклы статей и подкастов про корпоративную разработку веб-проектов.
Первым циклом будет серия статей про техническое задание: зачем и в каких случаях оно необходимо, как разрабатывается и применяется в ходе реализации проекта, какой должна быть структура и как написать техническое задание.
Сегодняшняя статья посвящена теме необходимости технического задания.
И прежде чем ответить на этот вопрос определимся с тем, какие заказчики заказывают проекты, и какие исполнители их реализуют.
Определим следующие категории:
Малый бизнес (МБ) — характеризуется тем, что у компании еще нет сильно развитой инфраструктуры и отсутствует экспертиза в реализации ИТ-проектов (тут я имею в виду, что полностью отсутствует ролевая модель с выделенными специалистами по маркетингу и ИТ).
Средний бизнес (СБ) — характеризуется монолитной инфраструктурой (работы по развитию инфраструктуры в компании не постоянны, а по потребностям). Также в среднем бизнесе присутствует понимание рынка заказной разработки, но отсутствует углубленная техническая экспертиза (топ-менеджмент с опытом, но без штата специалистов имеющих углубленные понимания процессов реализации проекта).
Крупный бизнес (КБ) — характеризуется постоянно развивающейся инфраструктурой и наличием профильной экспертизы внутри компании и распределенной по отделам ролевой моделью.
Стартапы (С) - нередко характеризуются наличием углубленной технической экспертизы, но отсутствием инфраструктуры (оно и понятно, поскольку они чаще всего приходят с деньгами за развитием инфраструктуры и созданием технологического решения).
Хочу обозначить два момента:
1. Под экспертизой подразумевается совокупность софт-скилов и технических компетенций
2. При обозначении распределенной ролевой модели, я подразумеваю, что в компании есть отдельные топ-менеджеры по направлениям маркетинга и ИТ, и соответствующие отделы с профильными специалистами.
В данном перечне отсутствуют типы заказчиков, которых я больше отношу к частным случаям будь то:
Заказчики, желающие сотрудничества по разработке продукта, не имея бюджета (просящие в долг).
Госкорпорации и государственный сегмент.
Крупные компании, самостоятельно работающие с исполнителями по модели аутстаффинга.
Небольшое отступление, бус-фактор (Bus factor) — это параметр, определяющий сколько человек должен потерять исполнитель, чтобы проект не имел возможности и смысла дальнейшей реализации с данным исполнителем. Чем данный параметр выше, тем лучше.
Фрилансеры (Ф) — характеризуются формой организации (чаще всего это самозанятые, либо ИП) и уровнем компетенций, который определим как средний, поскольку рынок перенасыщен низкоквалифицированными кадрами, а высоко компетентные специалисты уходят в найм, либо развиваются в открытие своего собственного дела.
Ролевая модель проекта закрывается только посредством кросс-функциональности отдельных специалистов. Самый низкий бус-фактор среди всех исполнителей.
Лоукостеры (Л) — характеризуются отсутствием экспертизы у подавляющего числа специалистов в компании, и в то же время очень хорошими компетенциями в сопровождении клиентов, и в продажах. Ролевая модель закрывается отдельными специалистами, но при этом узкопрофильные эксперты отсутствуют.
Бус-фактор максимально высокий из всех видов исполнителей на рынке.
Бутик (Б) — характеризуется высокой экспертизой у всех участников реализации проекта, но при этом ограниченным объемом ресурсов. Ролевая модель закрывается отдельными экспертами, но присутствуют случаи частичного сопряжения ролей.
Бус-фактор низкий.
Фабрика (ФБ) — характеризуется уменьшением экспертизы (в сравнении с бутиком) за счет размытия компетенций при увеличении штата.
Кросс-распределение обязанностей отсутствует.
Бус-фактор высокий.
Гибридный Бодишоп (БШ) — характеризуется очень большим объемом доступных ресурсов и системой обособленности команд разработки. Бус-фактор компании выше чем у фабрики, но для отдельно взятой команды ниже. При этом компетенции аналогичного уровня, что и у фабрики.
Небольшая ремарка относительно «гибридного бодишопа». Бодишоп — это компании работающие по модели аутстаффинга. В России это не так распространено как на западе. У нас крупные компании такого формата позиционируют себя как разработчики проектов на заказ, предлагающие аутстаффную модель сотрудничества.
Мы определили виды заказчиков и исполнителей
Теперь перейдем к классификации типов технического задания.
Однозначно написать техническое задание, которое будет полноценно использоваться при реализации проекта, это большая работа. Потому разделим техническое задание на два типа:
Необходимое для формирования юридических рамок (Юридическое ТЗ).
Включающее предыдущее и достаточное для определения конечной формы реализуемого проекта (Полное ТЗ).
Юридический вариант ТЗ имеет один неоспоримый плюс, можно быстро приступить к работе и углубиться в сотрудничество.
Первый тип ТЗ можно описать двумя крайними видами:
Жесткое (шаг влево, шаг вправо — допы): такая форма применяется у лоукостеров и фабрик с готовыми решениями. Они работают с определенной аудиторией заказчиков для которой реализация проекта идет рука об руку с экономией. Поскольку такие проекты очень сильно похожи друг на друга, то у исполнителей уже есть шаблон ТЗ в который необходимо вписать пожелания заказчика, а функциональность, используемая при реализации проекта, будет типовой.
Мягкое: такая форма ТЗ удобна для фрилансеров и бутиковых агентств, так как сохраняет творческую свободу и размывает ответственность за реализацию проекта между заказчиком и исполнителем. Но это обоюдоострый меч: для обеих сторон наличие только юридических рамок переносит ответственность за конечный результат в плоскость коммуникаций, договороспособности и управления ожиданиями друг от друга.
Теперь рассмотрим второй тип — Полное ТЗ, которое дает ярко выраженное представление для всех сторон о конечном результате.
Может показаться, что такое техническое задание - это идеал желаний для любой компании, но тут возникают свои подводные камни строгой работы по техническому заданию. Мнение людей по одному и тому же вопросу, по которому был достигнут компромисс, может изменяться, а это, в свою очередь, накладывает обязательство поддерживать такое техническое задание в актуальном состоянии на протяжении всего проекта, что несет дополнительные затраты на реализацию проекта, но может уберечь от расхождения ожиданий и действительности при достижении цели. С другой стороны, техническое задание может быть достаточно информативным чтобы у проекта был описан путь реализации, но оставалось место для гибкости принятия решений.
Обозначим данные два вида технического задания как строгое и творческое:
Строгое техническое задание подходит для всех исполнителей, для которых проект является просто возможностью увеличения нагрузки на компанию. И это очень хорошо для определенного вида проектов, и для заказчика, у которого есть хорошая техническая экспертиза. Эффективнее всего такое техническое задание для работы с фрилансерами, фабриками и гибридными бодишопами.
Для лоукостеров это приемлемый вариант, поскольку они могут позволить себе увеличение объемов работы для компенсации неточности реализации, при этом не выходя за рамки бюджета, что они спокойно делают за счет финансовой модели реализации проектов. Для бутиковых компаний такое ТЗ накладывает ограничения, в связи с которыми они теряют свое основное конкурентное преимущество - влиять своей экспертизой на проект.
Творческое техническое задание — это форма, в которой у опытной команды есть возможность реализовать весь свой потенциал и полноценно внести в проект свою экспертизу.
При таком формате у заказчика есть возможность апеллировать ТЗ при определении уровня качества реализации, а у команды появляется ответственность провести согласование всех творческих решений и реализовать проект с обозначенным путем реализации.
Такое ТЗ подойдет для сотрудничества с фрилансерами, бутик-компаниями и фабриками.
При работе с гибридным бодишопом возникнут вопросы по отношению к качеству креатива полученного от такой компании: заказчик получит высокий уровень качества реализации кода, но визуальная составляющая будет определяться специализацией исполнителя и может быть ситуация, при которой у конечного исполнителя, работающего с проектом, не будет опыта работы с нишей заказчика.
Для лоукостеров такое ТЗ как точка роста, если у исполнителя есть выделенная команда для таких проектов. В противном случае заказчик может не получить того уровня качества, которое ожидает.
Обобщим: есть 4 вида заказчиков, есть 5 видов исполнителей и 4 вида технического задания.
Для начала надо понять: нужно ли для проекта полноценно сформулированное ТЗ, и надо ли на это тратить ресурсы или можно обойтись юридическим, либо вовсе работать без него.
С каким бы из исполнителей не работал заказчик, если бюджета на техническое задание нет, то этим можно косвенно определить вид проекта как типовой, и тогда необходимо выбрать с каким из исполнителей заказчик сможет работать на основании юридического технического задания.
В случае если денег нет совсем, то можно работать с лоукостерами или фрилансерами. С кем именно работать - лучше определиться, основываясь на наличии экспертизы со стороны заказчика.
Если заказчик понимает как устроены все процессы реализации проекта и может ими управлять, то лучше к реализации проекта привлечь фрилансеров.
Соответственно, если у заказчика отсутствуют необходимая экспертиза, лучше выбрать лоукост компанию.
Что при этом делать если бюджет есть, но он ограничен и строго регламентируются его расходы (очень актуально для грантовых проектов) или когда нет времени на реализацию технического задания в связи с малыми сроками на реализацию проекта (например, у заказчика через 3 месяца запуск рекламной компании)? В такой ситуации можно работать с бутиковой компанией: да, заказчик оплатит дороже, чем если бы обратились к фрилансерам или лоукостерам, но в конечном итоге получит более качественный результат вследствие большей экспертизы. Плюс, реализация качественного проекта для бутиковой компании - вопрос репутации (поскольку большая часть таких компаний работает, в основном, на эффекте сарафанного радио, и прямом выходе на клиентов).
При этом надо понимать о каких цифрах идет речь в вопросе выделения бюджета на техническое задание.
Юридическое ТЗ можно реализовать без бюджета. В таком формате в первую очередь заинтересован исполнитель, который готов работать с бюджетом заказчика.
В случае, если мы говорим о крупном проекте стоимостью от нескольких миллионов рублей, то я рекомендую выделять около 10% доступного бюджета на написание ТЗ. Чем объемнее проект в трудозатратах, тем больше должно быть проведено подготовительной работы, начиная с текстового описания и заканчивая маркетинговыми исследованиями и разработкой прототипов.
В случае, когда бюджет на реализацию проекта выделен большой, однозначно надо писать полноценное ТЗ, а не ограничиваться только юридическим.
Если заказчик не может это сделать самостоятельно, есть два варианта:
Доверить данную задачу консалтеру, который может в последствии на себя взять работы по управлению проектом со стороны заказчика.
2. Доверить написание технического задания исполнителю, которого заказчик выбрал для дальнейшей реализации проекта.
Но тут есть риск: когда исполнитель понимает, что он будет являться подрядчиком по проекту, качество реализуемого ТЗ может упасть, и если заказчик не обладает технической экспертизой, он может оплатить юридическое ТЗ по цене полного.
Что делать заказчику, чтобы потратить деньги выделенные на проект эффективно, если есть понимание, что это крупный нестандартный проект:
1. Не работать с лоукостерами. Основа работы с ними в их подходе к рынку: они не накапливают экспертизу для реализации крупных проектов (все банально - чем больше сотрудник иполнителя понимает и умеет, тем дороже он стоит для исполнителя, что в свою очередь влияет на стоимость реализации проекта для заказчика: им невыгодно накапливать такую экспертизу для работы с крупным бюджетом в случае, если они работают в сегменте небольших лоукост проектов).
Заказчик может попробовать самостоятельно собрать команду для своего проекта если внутри есть управленческая и техническая экспертиза, и заказчик имеет время для поиска и формирования команды. Плюс такого подхода в некоторых формах владения интеллектуальной и авторской собственностью разрабатываемого проекта, в том что заказчик может за меньшие деньги получить намного больше трудоресурсов для своего проекта, но вместе с тем он берет на себя все риски по реализации проекта, простою сотрудников. При этом, ему надо прогнозировать какой рентабельной нагрузкой он обеспечит сотрудников по завершению проекта. Минус такого подхода в том, что экономия такого характера не всегда выгодна (пример: выплачивая специалисту на руки зарплату в 120 тысяч, заказчик сверху еще платит 59 тысяч налогов, и в итоге, в годовом обороте это 2 330 000 расходов), а заказчик при этом имеет доступ к экспертизе только внутренних сотрудников.
Может появиться соблазн заменить работников в штате на фрилансеров для доступа к большей экспертизе, и большей экономии, но это еще больший риск для заказчика который попробует реализовать крупный проект таким способом. Надо уметь найти, привлечь и уметь управлять такими сотрудниками. При этом, хочу сказать, что за все время моей карьеры, я видел ИТ-компании и заказчиков, которые привлекали фрилансеров на проекты, видел несколько успешных кейсов привлечения их на разовые работы, и намного больше кейсов, когда проекты полностью проваливались при неумении управлять и прогнозировать работу с такими людьми, хотя работы там было на пару сотен часов).
У нас остается три варианта не учтенных исполнителей для реализации крупного нестандартного проекта:
Работа с бутиковой компанией имеет свой риск ввиду ограниченности ресурсов исполнителей для проекта. Чтобы это нивелировать необходимо максимально спрогнозировать потенциальные точки расширения со стороны заказчика, поскольку в случае, если это не будет учтено, то проект может выйти из под контроля (так бывает часто, поскольку в ходе реализации у заказчика просыпается аппетит, а формат бутика в том, что там нравится подход к работе, и сложно остановиться, когда у компании при этом есть бюджет. Но правда такова, что бутик не может уйти в работу с одним заказчиком на годы, и не может поставлять высококвалифицированные кадры, забирая их с рынка (формат компании не такой)).
Работая с фабрикой, имеется риск реализации проекта только частично исполнителем, а частично субподрядчиками, работающими под этой фабрикой. По факту заказчик может попасть в ситуацию, когда вследствие такой работы получит меньше ресурсов на реализацию проекта, чем предполагает его бюджет. Чтобы избежать этого необходимо в договоре прописать запрет на привлечением третьих лиц к реализации проекта. Если исполнитель не готов подписывать такой пункт, то заказчик явно будет переплачивать за цепочку субподрядов.
Работа с гибридным бодишопом, в целом похожа на ситуацию работы с фабрикой, но в данном случае заказчик получит отдельно выделенную команду под проект. В целом рисков меньше, но и проект может оказаться не приоритетным для такого исполнителя. В текущей рыночной ситуации, когда бодишопы ориентируются на закрытие потребностей цифровых гигантов, заказчик может столкнуться с ситуацией, когда будет дедлайн на работу с тем или иным специалистом.
Когда необходимо написание полноценного технического задания:
когда на стороне заказчика нет компетенций по реализации проекта .
когда заказчик выделяет большой бюджет на проект.
когда в проекте не предполагается интенсивного участия заказчика в ходе реализации проекта.
Когда можно использовать юридическое ТЗ:
когда между заказчиком и исполнителем уже выстроены взаимоотношения и обе стороны имеют положительный опыт работы друг с другом.
когда разрабатывается типовой проект.
И техническое задание не нужно:
когда со стороны заказчика присутствуют высокие компетенции и ресурсы на сопровождение реализации проекта.
когда заказчик формирует внутреннюю команду разработки, где надо выстраивать процесс и писать спецификацию, а не ТЗ.
В конце хочется напомнить, что разработка любого проекта это, в первую очередь, коммуникация между людьми. Учитесь договариваться с теми, с кем вам хочется работать.
Ну и по традиции пикабу, что бы меня было за что хейтить), выкладываю ссылку на телеграм канал https://t.me/skillline_ru. Там я опубликовал подкаст по данной теме.
И бонусом: если у вас есть техническое задание, и вам нужно проконсультироваться, я готов вам бесплатно помочь (под помощью подразумевается: вычитать ваше ТЗ, определить его слабые и сильные стороны, ответить на ваши вопросы). Для этого пишите в телеграмм @EKovalevich
Недавно завирусилась история о том, как кандидат вписал себе в резюме фиктивных два года опыта и прошел интервью на позицию в ИТ-компанию. Правда потом об этом узнали, и его вроде как уволили. Я не придал этому значения, пока мне не рассказали, что в одной онлайн-школе этому прям учат студентов, такая вот "гарантия трудоустройства". А на днях в одном из hr-чатов выложили фейковое резюме тестировщицы с 2 годами опыта, которая не смогла ответить ни на один технический вопрос.
В общем, весь этот треш оказался ближе, чем кажется. Не буду рассказывать, что обманывать нехорошо. Но я обратился за рекомендациями к Оле - HR в ИТ, карьерному консультанту и автору канала про карьеру, с которой мы трудоустроили уже ни один поток моих учеников.
Далее от ее лица.
Итак, последствия таких обманов могут быть разными:
(1) резюме могут закинуть по разным чатам и потом, чтобы найти работу, придется менять еще и фамилию (внутри одной сферы обычно тесно общаются и репутация дорога)
(2) в крупных компаниях есть службы безопасности, которые проверяют биографию еще до трудоустройства.
(у меня, кстати, был случай, когда клиентке отказали на последнем этапе из-за того, что данные из анкеты не совпали с реальностью)
(3) даже если все получилось, но в процессе работы информация вскрылась, могут и скорее всего уволят.
!(4) и что-то новенькое: hh.ru, на котором размещаются резюме, начал проверять точность информации и связываться с работодателями.
Поэтому поговорим о том, как можно привлечь внимание к себе, чтобы потом не уволили, как в этом случае:
(1) Начинать искать как можно раньше (когда изучена уже какая-то база), потому что то, что дают на курсах не всегда равно требованиям компаний. Чем больше смотрите вакансии и общаетесь, тем лучше понимаете, что нужно рынку.
(2) Использовать нетворкинг - знакомиться с людьми, которые работают в тех компаниях, куда вы хотите. Даже просто написать и попросить зарефералить. Теория с рукопожатиями тоже работает (у меня так много клиентов и знакомых нашли работу)
*кстати, консультант тут тоже обычно помогает и закидывает резюме по своим каналам (это, конечно, не гарантия успеха, но повышает конверсию)
(3) Резюме должно быть продумано до мелочей, из самого базового:
➡️ название должности должно соответствовать названиям вакансий, т.е не "специалист", а максимально конкретно;
➡️на первом месте должен быть опыт по той вакансии, на которую вы хотите, даже если это учебный опыт;
➡️ расписать подробно навыки, которые вы получили на обучении, лучше сразу с примерами из практики.
(4) Брать из предыдущего опыта все навыки, которые могут быть полезны. Смена направления — это не начинать с нуля, всегда есть переносимые навыки. Например, опыт ведения коммуникации и работа в команде, который есть у всех, и другие soft skills. Успех поиска 50/50 зависит от hard и soft skills.
(5) Использовать сопроводительные письма и писать вдумчивые отклики на позиции (спам-рассылка скорее всего не даст результата). А вот резюме + нормальное сопроводительное можно отправлять не только на hh, но и напрямую в компании, даже если вакансии нет, вас могут добавить в базу и написать позже.
*я всегда читаю, когда вижу, что человек постарался, а иногда даже даю обратную связь и помогаю скорректировать.
(6) Использовать разные источники поиска, в том числе рассматривать стажировки, после которых можно трудоустроиться (иногда это быстрее, чем искать вакансии).
Да, рынок очень поменялся за последние несколько лет, и все эти шаги объединяет активность и инициативность. Пробуйте разные гипотезы, потому что если не делать, то точно не получится. И пишите в комментариях, если нужен подробный разбор того, как правильно составлять резюме.
Всем привет, работаю java разработчиком 10 лет. Хотел бы на примере пояснить, почему важно внимательно вникать в требования, и не допускать их избыточного утяжеления.
Представим, что нам нужно сделать систему, проводящую платежные поручения, и у каждого поручения должен быть свой уникальный идентификатор. Поддержку уникальности осуществляет реляционная база данных, идентификатор используется как primary key. Какой тип и правило задать для генерации идентификатора?
integer, числовая последовательность: 0001, 0002, ...
UUID.random() : 8c061868-5bbd-4ea7-824f-d8640fb4f6e3, ...
UUID может совпасть при двух генерациях, но с крайне малой вероятностью - можно сказать что он уникален. Значения в последовательности тоже уникальны. То есть уникальность поддерживается там и там.
Так как эти уникальные значения можно сравнивать, то можно привести их к полному порядку - отсортировать и расположить в виде структуры с эффективным доступом (например, дерево со сложностью logN).
Числовая последовательность обеспечивает не какой-то порядок - он еще и совпадает с порядком добавления записей в таблицу. Если в конце месяца мы захотим подарить подарок 1000-му пользователю сервиса, то это можно сделать если исходный порядок сохранен.
В большинстве реляционных баз реализована поддержка реплик - узлов в резерве, на случай падения основного узла, осуществляющего запись. Реплики копируют данные с основного узла с небольшим отставанием, например последний платеж может в какой-то момент времени еще не дойти до реплики:
main: (0001, 0002, 0003)
replica: (0001, 0002)
Если основной узел выйдет из строя, то дальше все операции по записям возьмет на себя реплика. В указанном случае она будет выдавать идентификаторы далее: 0003, 0004, ... . Получается, у разных узлов будет разное представление об операции с id = 0003 - это создаст конфликт, если первый узел вернется к жизни.
Можно было бы вместо этого выбирать тысячную запись не по id, а по времени создания. В этом случае можно использовать UUID как идентификатор, и добавлять время создания записи, чтобы позже по нему выявить 1000-го пользователя. В случае падения основного узла конфликта с id не будет, но на разных узлах может не совпадать время - а это бывает при проблемах с ntp сервисами. Например, во время выхода из строя основного узла время на нем было 15:20, а на реплике 15:12, и у новых пользователей время будет меньше чем у существующих.
Еще можно было бы согласовывать следующее число в последовательности общим решением всех узлов, но такой подход более затратен и имеет свои проблемы.
На этом примере видно, что разработчику стоит строго фильтровать требования от бизнеса - пользуясь глубоким пониманием используемых решений давать справедливую оценку сложности доработок. Всем удачных проектов и профессионального роста!