Программист сделал сайт, не соответствующий изначальным требованиям заказчика, но договора не было

Как грамотно составить задание для программиста — Личный опыт на vc.ru

Программист сделал сайт, не соответствующий изначальным требованиям заказчика, но договора не было

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

В обратную сторону ситуация схожа. Многие компетентные исполнители (проблема актуальна же не только для программирования) жалуются на аналогичное поведение заказчиков: задержку постоплаты, требования выполнить не оговоренные ранее работы под предлогом «это же логично» или «сделай бесплатно, получишь второй проект» и так далее.

Само собой, причина этих проблем либо в желании откровенно кинуть партнёра, либо в недоговорённостях на старте. Про обман в этой статье писать не буду: это отдельный объёмный материал, связанный с юридической грамотностью и своевременностью подписания бумаг. Сегодня речь про второй вариант, когда «вроде договорились, но каждый понял по-своему» и о том, как избежать связанных с этим проблем.

Стандартные процессы разработки

Обычно процесс идёт по двум сценариям. Либо крупная подготовительная работа с написанием большого ТЗ и уточнением всех нюансов, либо, наоборот, прошлись по верхам, а детали обсудим в процессе. И у того и у другого способа есть плюсы и минусы. Уверен, большинству читателей они знакомы, но давайте всё-таки зафиксируем, чтобы было от чего отталкиваться.

Большое и долгое ТЗ

На картинке я показал, что ТЗ прорабатывается до КП, но некоторые студии меняют эти этапы местами. Для текущего вопроса это не принципиально, поэтому я объединил в один формат.

  1. Исполнитель и заказчик достаточно плотно разобрались в проекте и согласовали хотя бы глобальные вопросы, что снижает риск недопонимания.
  2. ТЗ прикладывается к договору и в случае проблем можно будет вспомнить и разобраться, нужно ли реализовать те или иные функции.
  1. В ходе реализации проекта у заказчика может поменяться виденье того или иного блока, что приведёт к переписыванию ТЗ, заключению дополнительного договора и тратам.
  2. Если работает команда, то не стоит надеяться, что за огромной кучей страниц ТЗ каждый из участников проекта увидит именно ту идею, которая лежала изначально. Расфокусировка будет обязательно.
  3. Без гарантий заключения сделки мало кто из исполнителей будет помогать с грамотным составлением ТЗ.
  4. Если покупать написание ТЗ, то опять же есть шанс, что будет написан огромный, технически верный проект, не отражающий, однако, ключевых требований.

К слову, самое большое ТЗ, которое нам приходило на оценку — 136 страниц двенадцатым шрифтом. Я отказался его брать в работу даже на оценку, так как времени потратил бы столько же, сколько на семь-десять других клиентов, но с меньшей конверсией в продажу.

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

Хоп-хоп и в продакшн

Немного изменил распространённое выражение, чтобы редакция не забанила, но общая суть второго подхода иллюстрируется им лучше всего. Это происходит, когда заказчик считает работы достаточно простыми и не требующими обсуждения. Шутки в стиле «там всего лишь лендинг с функцией магазина и социальной сети» и «что там делать этот Google, там же одна строка поиска» из той же оперы.

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

Процесс практически идентичен процессу выше за исключением того, что на первом этапе проговаривается базовая идея и сразу начинается работа

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

Выводы из обоих подходов

Принципиальными я вижу следующие вопросы, которые нужно регламентировать в процессе и которые влияют на положительный итог проекта:

  • Вся команда должна чётко понимать основную идею и ключевые функции.
  • Основные, влияющие на стоимость работы должны быть прописаны в ТЗ.
  • Должна быть возможность мягкого и понятного ценообразования изменений.
  • На старте, без серьёзных временных затрат, нужно иметь возможность дать предварительную оценку, которая не сильно (не более, чем на 20%) изменится после уточнения деталей.

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

Общая оценка. При входящем обращении, в ходе диалога на 15–30 минут или первичной переписки, выясняется идея проекта и основная бизнес-логика. На основе этих данных смотрим, что мы делали или оценивали ранее, какие были бюджеты у похожих приложений.

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

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

Разработка проекта

Если клиента устраивает оценка, следующий этап — проектирование. Проектирование сводится к пяти основным разделам:

  • Вводная задача от клиента: та самая идея, которой должно быть пронизано всё приложение.
  • User-case: описание последовательной логики работы всеми ролями пользователей.
  • Структура: список экранов приложения с указанием на цель того или иного экрана и принципы его работы, а также дополнительные функции (интеграции с 1С и эквайрингом, авторизации через соцсети и прочее на что не требуется доп экраны).
  • Смета: рассчитывается стоимость работ на основе количества экранов и сложности дополнительных функций. Для проектов с базовым дизайном и индивидуальным, само собой, стоимость экранов разная, поскольку отличается объём работ, а дополнительные функции считаются по временным трудозатратам.
  • Рекомендации: на основе опыта работы с подобными проектами даём рекомендации по развитию сервиса после запуска.

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

Публично показать примеры проектов не могу, так как это будет некрасиво по отношению к клиентам (я против подхода «взять чужую идею и допилить под себя»), но могу показать те проекты, сильно отличающиеся от вашей идеи в индивидуальном порядке. Для этого напишите мне во «ВКонтакте» или .

Цель этого этапа — додумать за заказчика те или иные решения и согласовать ключевой функционал.

Прототипирование

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

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

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

Заключение

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

  • Понимание идеи всей командой. Благодаря расписанному юзер-кейсу и чёткой структуре, а также небольшому объёму информации, любой участник проекта понимает, что он делает и какая цель того или иного блока.
  • Принципиальная функциональность. Все важные функции и экраны описаны в структуре. Заказчик тоже через ценообразование понимает, что, например, добавить новое поле в экран заявки дополнительных денег стоить не будет, но если нужно сделать новый экран или подключить эквайринг, который изначально не был заложен, то это дополнительные деньги.
  • Понятное ценообразование. Ещё на этапе проекта в разделе сметы показывается, что каждый экран стоит, например, 11 тысяч рублей, значит, и при добавлении ещё одного стоимость экрана будет такая же. Если интеграция трёх соцсетей стоит 4800 рублей за каждую, четвёртая будет стоить те же 4800 рублей.
  • Предварительная оценка. На этапе пресейла не пишутся и не изучаются никакие длинные документы, а вопрос «сколько примерно стоит» решается за 15-30 минут.

Источник: https://vc.ru/life/64460-kak-gramotno-sostavit-zadanie-dlya-programmista

В твери программисты-самоучки создают игры и получают заказы со всего мира

Программист сделал сайт, не соответствующий изначальным требованиям заказчика, но договора не было

Судя по последним пополнениям списка Forbes, в России миллиардерами становятся программисты и металлурги.

При этом сфера IT сейчас одна из самых перспективных и развивающихся в мире, не в последнюю очередь из-за того, что именно здесь наглядно работают социальные лифты.

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

25-летний Роман Стец родился, вырос и работает в Твери. Его компания Stets Media, открытая с нуля, создаёт виртуальные миры и модели дополненной реальности. География заказчиков – весь мир.

20-летний Виктор Цай приехал в Тверь из Москвы, он нашёл тут работу при посредничестве Романа. Начал Виктор здесь как ведущий разработчик, сейчас он уже стал руководителем проекта. Виктор работает в компании DreamVR и создаёт игры в виртуальной реальности.

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

Мы встретились в офисе DreamVR в центре Твери. Он располагается на мансардном этаже одного из торговых центров в двух шагах от улицы Трёхсвятской. Компания занимает половину просторного помещения.

Сотрудники начинают появляться на рабочем месте около 10 утра. Обычно все в сборе только к полудню. Но и работают допоздна. Гудят мощные компьютеры, на столах стоят по два-три монитора, прямо на полу с ковровым покрытием кучей свалены VR-очки, какое-то ещё оборудование.

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

Квадрат – это условные границы виртуальной реальности. Здесь тестируют игры.

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

Когда вы станете долларовыми миллионерами?

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

Роман – улыбчивый молодой человек. У него светлые волосы и приятная манера общения. Ярко жёлтая толстовка, телефон последней модели, быстрая речь и много идей.

– Что сказать о доходах? Благодаря работе в IТ я начал помогать родителям в финансовом плане, а у меня появилось больше свободного времени. Это, безусловно, даёт возможность сформулировать идеи и поставить задачи для реализации их в жизнь. Бывает, что всю свою зарплату вкладываю в развитие компании, бывало, что работал в убыток себе или за 0 рублей.

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

Но я постарался найти для них другую работу, – рассказывает он. 

Но в целом у компании дела идут неплохо, бизнес развивается. 

Виктор – бородач с фиолетово-красными волосами. Он носит очки, и вид имеет подчёркнуто гиковый. На фоне эмоционального Романа Виктор смотрится флегматиком. Ему только 20 лет, но выглядит он старше своих лет.

– Есть такое понятие в программировании как “технический долг”. Это если разработчики что-то сделали плохо, и из-за этого потом происходят сбои.

Например, второпях архитектуру игры прописали на десять участников, а потом, когда их количество увеличилось, появились “баги”, и игра не может нормально работать. Приходится что-то переписывать, переделывать.

Это и есть “технический долг”, я как руководитель проекта слежу, чтобы таких “долгов” не было. Так же я отвечаю за сроки сдачи, за качество проекта, веду разработку, то есть, ставлю приоритеты и задачи, а так же пишу ключевой код проекта.

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

– Это очередной этап. Мне нравится здесь работать, но не нравится жить. Я снимаю квартиру в Центральном районе и прихожу домой после работы около 12 часов ночи. В это время нет горячей воды. Мне приходится сливать её по полчаса, чтобы получить хотя бы тёплую. Когда снимал жилье в Пролетарском районе, такого не было, – рассказывает парень.

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

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

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

Где учат на программистов?

Роман не очень хорошо учился в школе, но в девятом классе увлёкся программированием, сам начал штудировать учебники по математике. У него появилась мотивация лучше учиться.

– Я сильно вырос в плане знаний за тот год, правда, мои учителя не поверили в меня, и в 10 класс в той школе меня не взяли. Я перешёл в другую школу, – рассказывает Роман.

Несмотря на все усилия, ЕГЭ он все-таки провалил, но смог сдать экзамены через год и тогда же поступил в технический вуз. Свои первые 100 тысяч рублей на программировании Роман заработал в 17 лет.

– Я нашёл человека, который тогда в Твери работал в Microsoft. Он показал мне языки программирования, указал направление развития. Тогда я сам создал коммьюнити программистов и собрал свою первую команду.

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

Но все получилось. Это была очень простая игра.

У Виктора Цая с учёбой в школе все было с точностью до наоборот. До девятого класса успеваемость была на высоком уровне, а потом пошла на спад. Именно из-за увлечения программированием.

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

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

И уже здесь поступил учиться в технический университет.

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

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

Заметим, что Билл Гейтс, Марк Цукенберг и Стив Джобс не имели высшего образования, когда заработали свой первый миллиард долларов.

Игра

– Детей, которые много играют, нужно ограничивать. Это не должно вредить учёбе. Есть игры, которые знакомят с программированием, их можно предложить ребёнку, чтобы заинтересовать его созданием игр, – говорит Роман Стец. Оба героя интервью признаются, что много играли в детстве. Но играть и делать игру – далеко не одно и то же.

– Игроманы, когда приходят попробовать делать игры, часто обжигаются, – добавляет Роман.

– Языков программирования в мире значительно больше сотни, среди них есть универсальные, на которых можно много чего написать, а есть узкоспециализированные: это как английский или древне-китайский какой-нибудь. Есть языки программирования, которые созданы ради шуток, – “Petooh”, например.

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

Так же получаются программы, приложения и игры, – рассказывает Виктор.

– Программирование – это лишь правила, на которых всё пишется. Благодаря языку программирования можно реализовать любой алгоритм. Чтобы описать трубу, нам надо знать её длину, диаметр и вес.

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

– Игры делаются на объектно-ориентированном языке программирования. На нём мы описываем человечка, который где-то стоит, куда-то смотрит, что-то держит в руках, имеет сколько-то здоровья и так далее, – поясняет Виктор Цай.

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

Идеи разработчики черпают из книг, кино, музыки, других игр.

– Однажды игра мне приснилась. А так вдохновение можно найти почти везде. Для меня, например, это игры от Blizzard, фантастические фильмы, – рассказывает Виктор. – Если говорить об игре мечты, то я сейчас как раз занимаюсь такой разработкой. Хотя это, наверное, всё-таки не прямо игра мечты, а та игра, в которую мне нравится играть.

Роман качает головой, игру мечты он ещё не создал. Хотя ему тоже как-то полностью приснился код, который он потом смог записать.
Помимо игр, компания Романа производит объекты дополненной реальности, например, телестудии, VR-аттракционы, кликеры (разновидность игр для смартфонов) и т.д.

– Я занимаюсь тем, что мне нравится, то, что я обожаю. Но я хочу большего. Развиваться в других сферах. А в IT… Вот история, ребята создали джойстик для полностью парализованного парня. Он может играть ртом, о нём узнали другие люди, они ему донатят, о нём пишут журналисты.

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

Мне хотелось бы сделать что-то подобное.

Игры не делают человека агрессивнее, убеждены оба программиста

– Наоборот, человек выплёскивает там агрессию, избавляется от нее, – говорит Роман.

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

В юности дофамин вырабатывается часто, с возрастом открытий становится меньше, дофамина меньше. Человек в игре получает награды и у него вырабатывается дофамин, он зарабатывает очки, опять вырабатывается дофамин, – объясняет Виктор.

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

Виртуальная и дополнительная реальность могут дать человеку новые эмоции и впечатления, и это интересно людям, которые хотят получить новый опыт, – например, попробовать прыгнуть с парашютом; полетать, как птица, и т.д.

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

Разработка собственного продукта, не под заказ, его продвижение и развитие – это самое перспективное, уверены оба программиста. Именно такая стратегия привела к успеху Сергея Брина, Марка Цукенберга, Павла Дурова, Игоря и Дмитрия Бухман из Вологды. Последние вошли в список Bloomberg в 2019 году и были вынуждены переехать из Вологды в Ирландию, написала “Медуза”. 

Кстати, в компании братьев Бухман “Playrix”, в то время она называлась “TerminalStudio”, работал отец Виктора Цая, как раз тогда, когда Виктор и увлёкся созданием игр.

программисты, it-компании, создание игр, роман стец, виктор цай

0 Подпишитесь на наш канал Яндекс.Дзен

Источник: https://tvernews.ru/news/252512/

Без ТЗ: как разработчики в такое ввязываются

Программист сделал сайт, не соответствующий изначальным требованиям заказчика, но договора не было

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

Версия 1: боюсь потерять клиента

Всем знаком этот первобытный страх! Он достался нам в геноме от пещерных программистов! Если я упущу этого клиента, то мне нечего будет жрать!!! Возьмите себя в руки, председатель! Пока мистер Без ТЗ жрет ваш мозг, за это время можно успеть найти более вменяемых заказчиков, и заработать гораздо больше. Потеря клиента лишь стимулирует активнее искать новых.

Иллюзия, что следующего заказчика придется искать очень-очень долго, развеется, когда вы сконцентрируетесь на оптимизации процесса поиска, технологии выявления наиболее выгодных заказчиков из всего мутного потока. Чем более вы активны, тем больше вас знают, тем больше к вам обращаются сами.

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

В отношениях с заказчиком должен присутствовать едва уловимый BDSM. Если вы ведете себя в духе “что барин изволит?”, то возникают подозрения, а не менеджер ли вы?

Версия 2: для друзей

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

Как вообще вы могли дружить столько лет? Если хотите делать проектик с друзьями, то окажите им услугу в составлении подробного ТЗ, позаботьтесь о тех, кто вам дорог. При этом нужно понимать, что вы скорее всего рассоритесь еще на этапе написания ТЗ, а то и раньше. Вот, вам занимательная история одного проекта “по дружбе”.

Моему близкому другу надо было срочно и недорого запускать интернет-магазин, потому как инвестор дал “добро”, и контейнер уже плыл из Китая. Я сразу предупредил, что это не совсем моя тема, так как я в основном работаю с корпоративными e-learning продуктами и медицинскими системами, но чего-нибудь придумаем.

Итак, инвесторские деньги выделились, и друг проявился в моем поле зрения с бодрым: “Ну, давай портфолио по интернет-магазинам! Мы подрядчика выбираем! Только присылай побыстрее, не затягивай!” Я слегка фаломорфировал о того, как быстро “Спаси-помоги, друг дорогой!” трансформировалось в: “Я пришел к тебе с редкой возможностью поучаствовать в моем тендере!” и слил кореша с формулировкой: “У меня тут заказ на несколько миллионов — сорри, сейчас некогда портфолио по магазинам собирать”. Друг обиделся, но сообщил мне, что я “всё равно в шорт-листе”. На том и порешили.

Версия 3: для себя

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

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

Какой простор для личной критики: “Я раньше и не знал, что работаю с такими конченными рукожопами!” А сколько можно делать правок! Когда логотип в шапке 18-й раз меняет свой размер на 2 пикселя, потому что “он всё ещё смотрится как-то непрофессионально”, вы начинаете чувствовать, что что-то пошло не так. Но оставьте сомнения! Вы же это не для клиента какого-нибудь, а для себя делаете! Так что не бойтесь еще раз 50 поменять концепцию — это точно поможет бизнесу! Вот почему часто внутренние проекты вполне успешных IT-компаний затягиваются на века.

Версия 4: начинающий разработчик берусь за любой ад

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

“Вот, мы тут делали… И почти доделали! Оно не работает, но, в целом, видно суть”. Если вы начинающий разраб, не стесняйтесь требовать ТЗ — это поможет вам отличить нормальных заказчиков от космонавтов, которые заставят вас возненавидеть профессию, себя и весь мир.

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

Частенько портфолио собираются по принципу: “Мужик, ты на Drupal-е чего-нибудь собирал в этом году? Дай списать!” Клиенты — такие затейники, и часто их не устраивает “просто портфолио”. С меня как-то потребовали портфолио CRM для ТРЦ, чтобы подтвердить мою компетенцию в данной области.

Версия 5: важный клиент

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

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

Я это к чему? В крупных компаниях работают как раз такие обезьяны: «У нас в компании принято платить за финальный результат с отсрочкой платежа 60 дней!». Что ж, тогда остается только опросить разрабов, получить среднепотолочную оценку «этого», умножить ее на 3… нет, лучше на 5, и смело вписывать в КП.

Купят – хорошо, не купят – и слава богу, потому что драть будут, как за Х10, всею вертикалью власти от младшего стажера до генерального. Конечно же, может найтись «свой хороший мальчик», который все сделает в два раза быстрее и дешевле.

Надо встретить такого мальчика с позитивом, пообещать помочь советом, если что! А ближе к концу (предполагаемому) проекта позвонить и поинтересоваться: «Как дела?». На самом деле, крупные компании не боятся крупных сумм, особенно если ты их можешь обосновать. Если ты выехал за их бюджет, тебя попробуют уломать на скидон.

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

Версия 6: неквалифицированные заказчики

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

Версия 7: программист на зарплате

Хорошая зарплата и кодить — это вторая по популярности мечта программиста после оплаты по часам. 250К, соцпакет и прямо в рай! И жизнь удалась! What a beautiful life! На самом деле, нет. Даже такие условия можно превратить в ад.

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

Разработчик на зарплате любезно сообщает ей, что она должна скачать с GitHub стандартную форму ТЗ (содержащую, например, такие поля как “требуемый уровень безопасности данных пользователей” и “предполагаемый уровень пиковой нагрузки на сервер”), заполнить её и закоммитить обратно. Подробную инструкцию о том, что и как, она без труда найдет на корпоративной вике.

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

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

Версия 8: лень, некому делать ТЗ

“Я разработчик, и я не хочу писать ТЗ, я хочу алгоритм и копи-пейст!” Но почему бы не попросить клиента решить эту проблему? Аналитик вполне может быть на стороне клиента и выдать что-то вполне вменяемое. Если аналитика нет ни у клиента ни у вас, ну так наймите же его и выставьте клиенту счет!

Версия 9: заказчик не знает как должно быть

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

очень многое пришлось придумывать самому — просто у молодого человека не было какого-то мнения по многим вопросам.

Бывает, что заказчик так и говорит: “Я не знаю, чего хочу — предложите варианты!” И очень хочется начать делать эти варианты, но надо взять себя в руки и составить ТЗ на варианты (да-да, варианты тоже должны делаться по ТЗ).

Версия 10: ради будущих крутых проектов

Когда я дописывал эту статью со своим прекрасным редактором, к нам пришел приятель и рассказал, что берется без ТЗ ради будущих проектов: — Сейчас возьмусь за копейки и без ТЗ, зато, потом они купят у меня мегапроект по нормальной цене! — Но почему?! — Я в это верю! И мне реально интересен этот проект! — Но почему они купят? — Аааа, не знаю! Ну, о-кей, вы меня застыдили! Я больше не буду так делать!

Версия 11: “Я хочу, чтобы у вас глаза горели!”

Бывают такие заказчики-искусители, шоу-мены, ораторы от бога, которые умудряются разжечь нехилый интерес к проекту даже у самого прожженного разраба с тленом в глазах. Я часто слышу именно такую фразу: “Я хочу, чтобы у вас глаза горели!” — и она сразу заставляет меня насторожиться.

Часто подобные заказчики сопровождают свои речи щедрыми обещаниями доли в проекте или роли эксклюзивного оператора сверх-успешного продукта или сервиса.

В общем, разработчик начинает верить, что делает проект для себя, а тогда зачем такие формальности, как ТЗ? Я безмерно уважаю людей с горящими глазами, но, пожалуйста, оставьте немного вашего сухого горючего на ТЗ!

Вывод

За всю мою деятельность отказ от ТЗ ни разу не помог упростить проект или заработок. Проблема в том, что в IT-проектах ТЗ пока не стало такой же обязательной частью подготовки.

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

PS: Не забываем писать в комменты почему и как вы взялись без ТЗ, кто вас к этому склонил, какие хитрости и уловки использовал.

UPD:

Тут пользователь сформулировал важные фундаментальные вопросы на тему «Что есть ТЗ? Что делает аналитик?», спасибо ему! habrahabr.ru/post/315624/#comment_9952198
Спасибо всем комментаторам, благодаря им обсуждение получилось гораздо интереснее, чем сама статья.

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

  • 2,3%Я заказчик: был доволен19
  • 20,7%Я разработчик: был доволен174
  • 2,3%Я заказчик, был расстроен19
  • 74,8%Я разработчик: был расстроен628
  • 19,4%Версия 1: боюсь потерять клиента164
  • 21,2%Версия 2: для друзей179
  • 20,8%Версия 3: для себя176
  • 28,6%Версия 4: начинающий разработчик берусь за любой ад241
  • 18,1%Версия 5: важный клиент153
  • 30,9%Версия 6: неквалифицированные заказчики261
  • 44,2%Версия 7: программист на зарплате373
  • 27,4%Версия 8: лень, некому делать ТЗ231
  • 46,4%Версия 9: заказчик не знает как должно быть392
  • 12,1%Версия 10: ради будущих крутых проектов102
  • 6,6%Версия 11: “Я хочу, чтобы у вас глаза горели!”56
  • 5,4%Есть еще версия, напишу в комментах!46
  • безтз
  • тз на программирование
  • тз на дизайн
  • тз
  • клиенты
  • клиентский сервис

Источник: https://habr.com/ru/post/315624/

За что увольняют программистов

Программист сделал сайт, не соответствующий изначальным требованиям заказчика, но договора не было

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

Код ради кода

«Наняли человека — хорошо прошел собеседование. Миддл. Сам меня нашел через DOU», — рассказывает Владимир Железняк, СТО небольшой продуктовой компании FundSeeder.

Через неделю ознакомления/работы новому сотруднику дали задачу — дописать пару строчек («отправить письмо по действию пользователя, см. пример, как мы это делаем вот тут»). В результате оказалось, что он переписал много старого кода, подтянул пачку новых библиотек.

По мнению руководства, для миддла на второй неделе работы в большом проекте — такое поведение несколько неожиданно.

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

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

В итоге эту задачу с отправкой письма возвращали на доработку два раза — и каждый раз там в коде было нечто очень неожиданное — новые директории, новый API и т.д. Это всё хорошо — но тогда, когда оно действительно нужно. Часто решить проблему можно намного проще и менее затратным способом — стоит только вникнуть и разобраться.

Чуть позже возник еще один случай — на двухнедельном Iteration Review подняли проблему, что есть задержка в несколько дней между запросом от пользователя и ответом саппорта.

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

А разработчик бросился предлагать решения, не понимая проблемы.

Сотрудника уволили на третьей неделе работы — за непонимание связи между написанием кода и бизнес-потребностями проекта.

А нам всё равно

О следующем случае рассказал Алексей Колупаев, СТО стартапа MeinFernbus. Когда искали программиста на одну из вакансий, им подвернулся кандидат, который не знал нужного фреймворка.

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

В 90% случаев соискатели после такого исчезают, но этот разработчик выполнил задание, показал нормальный результат, и его приняли.

Со временем, когда спала повышенная работоспособность, свойственная только что нанятым сотрудникам, оказалось, что новый сотрудник регулярно косячит, но не видит в этом какого-то экстраординарного явления, takes it easy. В принципе, человеку свойственно ошибаться, еще и новому. Но неприятные моменты накапливались. Выводы не делались.

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

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

После этого компания прервала его испытательный срок.

Сам себе на уме

Этот пункт посвящен непроработанным soft skills и навыкам личной эффективности.

Алексей Коваль, СТО проекта UA2WEB, сталкивался с ситуаций, когда проект перерос одного человека, а этот человек оказывается неспособным перестроиться с работы в одиночку на труд в команде.

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

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

Но, по словам Алексея, первая по количеству увольнений статья — это некачественная работа, когда человек, обладая знаниями и умениями, не выполняет задание из-за проблем с личной дисциплиной и организованностью.

Еще один кейс, о котором стоит упомянуть — когда специалист не желает выстраивать отношения с менеджментом компании. Такой случай был в практике Насти Шафрановой, hr-менеджера Timecode. Разработчик, хороший технический специалист, полностью игнорировал рабочие миттинги, не предупреждал, что у него не получается присутствовать. Пришлось с ним попрощаться после испытательного срока.

Похожая ситуация — некорректное поведение с заказчиком. По словам Сергея Немчинского, тимлида в IntroPro, если разговор об аутсорсе, то за подобные промахи людей увольняют в 24 часа. Слишком уж аутсорс зависит от заказчика. Жестоко, но вариантов нет — найти нового разработчика существенно проще, чем заказчика

P.S. Есть еще одна категория fire-листа — невыполнение рабочих обязанностей. Бывает, что человек старается, а результатов мало. Но тут, пожалуй, и так всё понятно.

Источник: https://dou.ua/lenta/articles/reasons-to-be-fired/

Прав-помощь
Добавить комментарий