Метка «заказчик»

Дано:

  • Исполнитель стандартный специализированный;
  • Заказчик неопределённой формации;
  • Заказ.

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

Первая встреча (она же и последняя)

Заказчик и исполнитель договорились о встрече, дабы обсудить выполнение заказа. Оба в предвкушении успешного финала. Заказчик готов изложить суть дела. Исполнитель в общих чертах оценил объем работ и среднюю стоимость или стоимости отдельных этапов работы.

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

Читать полностью »

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

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

Уточнения:

  1. Технические задания не пишут (составляют, подготавливают, оформляют и пр.), а разрабатывают, см. хотя бы п. 1.2 ГОСТ 34.602-89;
  2. Если заказчик и исполнитель руководствуются требованиями ГОСТов, то совершенно противоположных мнений у них в принципе быть не может и не должно. Если же взаимодействие осуществляется «по понятиям» — как сейчас принято — то без «плюрализЬма мнений» тут, конечно, никак не обойтись.

Читать полностью »

На одной из конференций произошел комичный случай. Подходит слушательница:

— Александр, есть такой вопрос: Как нам повысить уровень доверия в отношениях с заказчиком?

— А что сейчас не так с уровнем доверия?

— Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам…

— А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.

— Понимаете… Мы ему джуниор инженеров продаем как синьор инженеров… И нам не хотелось бы, чтобы он обнаружил этот факт.

Напомню изначальную постановку вопроса: “Как нам повысить уровень доверия в отношениях с заказчиком?”

Вот о заказчиках сегодня и поговорим. А точнее, о простом инструменте, который:

  • Поможет осознать, где находятся ваши отношения с заказчиком
  • Покажет, почему формы отчетов иногда бывают такие идиотские
  • Возможно, поможет понять причины “неадекватного” поведения заказчика

Читать полностью »

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

Читать полностью »

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

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

Читать полностью »

Думаю, многие слышали о законах роботехники, сформулированных Айзеком Азимовым:

  1. Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинён вред.
  2. Робот должен повиноваться всем приказам, которые даёт человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
  3. Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому и Второму Законам.

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

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

Цель урока: финальный урок по созданию приложения. Написание технического задания. Создание БД. Переименование webTemplate. Применение скаффолдинга. Админка. Основной сайт. Тесты.

О главном

Это финальный урок, и тут я немного отойду от конкретного программирования и поразмышляю о работе.
Программирование – это работа, это профессия, это творчество. Когда я учился в университете и с кем-то шел по дороге домой, мы часто спорили, что лучше Windows или Linux, Delphi или C++. Тогда мы могли не спать ночами, чтобы красиво переписать построение семантического дерева для компилятора. Мы изучали пролог, лисп, конечные автоматы, структуры данных. Мы учились видеть красоту быстрой сортировки Хоара реализованную на лиспе. ВО!:

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Но теперь я рассматриваю программирование как услугу. Как что-то, за что мне платят деньги. Я занимаюсь фрилансом уже три года. В начале работы фрилансером я программировал не только веб и не только на asp.net mvc. Был и php на ZendFramework, и написание модулей для расчета стратегий для торговли на РТС на Quirk.

Читать полностью »

Это мой первый пост на Хабре, поэтому не судите строго. Я достаточно много занимаюсь не только разработкой, но и постановкой процессов, в том числе тестирования. И всегда несколько скептически относился к ручному тестированию, точнее к той его части, которая отвечает за «обеспечение работоспособности существующей фунциональности» (в простонародье регрессионное тестирование). Что же плохого в этом тестировании и почему многие компании его тогда используют? Кто интересуется ответом на эти вопросы, могут потратить еще пару минут на дальнейшее чтение.
Читать полностью »

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

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

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

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

Почти все компании когда-либо являлись заказчиками различных IT-услуг будь то создание сайта, поисковое продвижение, реклама, интеграция продуктов типа 1С и т.д. Исполнителей много и качество оказываемых услуг разное.
Не хотелось бы поднимать вечную тему о том, как качественно выполнить задачу при минимальных бюджетах, а хотелось бы добавить немного “фана” в наш блог.
Наш главный разработчик Ла Суан Тханг умеет не только проектировать архитектуру программных продуктов, но и отлично рисует. Он изобразил на бумаге несколько примеров выполнения задач разными типами исполнителей и получилось довольно смешно.

Итак,Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js