Вот 5 минут назад обсуждал с камрадом ситуацию, которая наверное для многих знакомая – есть команда, работает на Заказчика 2недельными спринтами, 6 человек
, соответственно сухой остаток – 480 часов рабочего времени в спринт. Вот отработали очередной спринт, посмотрели сколько отрепортали часов. Получается 628. Это означает, что рабочий день каждого увеличился примерно на 2,5 часа – это если нагрузка была распределена параллельно. Как часто нагрузка распределяется равномерно? Ага, примерно когда рак на горе свистнет. Это значит, что некоторые камрады сидели на работе по 12-14 часов. При этом – сюрприз! – Заказчик не только платит всего за 480 часов, но и еще регулярно команду “прикалывает” – мол, плохо работаете, товарищи, давайте напрягитесь, а то вот отдам вам контракт малазийцам…И так каждый спринт. Я должен принимать работу регулярно? Забудьте! 40 Hrs workweek? Ничего про это это не знаю! Команда как главная ценность? три раза ха-ха! Что в такой ситуации делать?
Мне эта ситуация живо напомнила момент, когда я перестал работать один и нанял несколько человек – человек стоит в месяц столько, что поневоле стараешься его побыстрее пристроить куда-нибудь на проект как можно скорее. А я от большого ума нанял людей в тот момент когда сам смог поднять башку – а случилось это аккурат в середине лета. Кто в курсе аутсорсингового бизнеса – тот знает, что имеет место быть сезонность – конец лета и январь-февраль часто практически дохлые месяцы, активность замирает (это не у всех так, но довольно часто). Ну вот и у нас так случилось. 3 нанятых человека быстро кушают “рабочий капитал”, и в сентября я был готов их ставить куда угодно, а они работать с чем угодно лишь бы работать. Ну и мы похватали первые попавшиеся проекты, через “не могу”.
О мама дорогая, рассказать как там чудили Заказчики – так не поверите. И какие мы делали грязные хаки – сейчас просто жутко вспомнить. Тестирование оплачивали из своего кармана – так как Заказчик не платил, а без тестирования порождаемая хрень просто не работала. Работать нормально – Заказчики не хотели: хапарай по понятным причинам их вполне устраивал. Короче, по нагрузке – караул, по прибыли – самоокупаемость. И мы довольно долго так парилились – пока не обнаружили, что есть новые клиенты – которым надо побольше, и которые повменяемей, и платят регулярно. И тогда я просто расставил точки над I. Так что первый пункт плана выхода из мрачной ситуации:
Пусть у вас будет из кого выбирать – пусть у вас будет целый пайплайн Заказчиков, которых вы будете slide’n’dice по прибыльности, лояльности, объему переработок. Тогда в ответ на фразу “а не отдать ли мне контракт…” вы будете смело отвечать – “это как вам будет угодно, мы парни занятые”. Чтобы вам было из кого выбирать – вы должны быть Заказчику нужнее, чем он вам. Спокойно, это не так сложно как вам кажется – если вы делали с нуля систему последние три года, не выполняя рефакторинга и не ведя документации (Заказчик ведь настаивал что это лишнее?) – то стоимость передачи проекта от вас другой команде и связанных с этим потерь будут зверскими. Так что даже простое обозначение своей позиции (“а передайте, мы спокойно к этому относимся”) уже будет как удар поддых. Ну и третье – после обозначения своей позиции (“уважаемый, ты нам не благодетель – ты платишь, мы – работем. Не платишь – не работаем. Недовольны друг другом и не находим решение – расходимся.”) работаем по схеме Underpromise – Overdeliver. Это очень просто – Заказчику обещаем не золотые горы, а только то, что реально сделаем. И вот это – умри, но сделай. И еще шмат поверх. И в итоговом отчетет – шмат сделанный поверх обязательно выдели цветом.
Означает ли это, что ты вообще обойдешься без экстра-работы? Нет, ни за что – и если ты не круглый дурак ты не будешь брать за это денег. Но эта экстра-работа – будет выполняться не вынужденно, а добровольно, и будет четко понятно – что это твой жест доброй воли. Заказчик говорит “съэкономлю на тестировании”? Скажи ему “нет”. Заказчик говорит “давай поработай по 12 часов”? Скажи ему “нет”. Заказчик говорит “используй копипасту”? Скажи ему “нет”. Заказчик настаивает на нарушении development fundamentals? Скажи ему “нет”. И это твое “нет” – оно поможет сделать проект. “Ай-яй, мы потеряли заказчика!” Нет, вы только что избежали больших проблем – ведь у вас в пайплайне еще два десятка.
То есть если коротко – у тебя должна быть возможность сказать “нет”. Когда ты убираешь из головы дурацкую максиму “клиент всегда прав” (рекомендуется попробовать адресовать стоматологам и нейрохирургам) – вокруг открывается много интересных возможностей, и управление ожиданиями становится простым и понятным.
З.Ы. Перед тем как сказать “нет” – 3 раза объясни почему нельзя. И вот если даже после этого не понял – это карма, как говорят японцы.
Вот почему я не люблю service development. Product development по сравнению с ним просто рай.
Тоже конечно есть проблемы с заказчиками и под кого-то приходится прогибаться. Но случалось это редко. В последнее время я пришел к мысли что даже такие редкие прогибы надо убирать нафиг, потому что страдает общая стратегия развития продукта.
В продукт девелопменте одна глобальная проблема - расстановка приоритетов