Все зависит от того, что вы за программист. Простому кодеру формошлеперу, нет смысла. Инженеру, который очень четко хочет понимать бизнес требования из первых уст, есть смысл.
Для начала, не мешало бы примерить эту же рубашечку на себя. А то получается, что кругом одни дебилы, а вы такой, на белом коне. Интересно было бы услышать мнение о вас от этих, упомянутых вами, сотрудников. Было бы безумно любопытно.
А вообще, работать с людьмы - это не каждому дано. Это намного сложнее, чем код писать, или строчить статейки о своей некомпетентности. А именно так я ее и восспринимаю, к сожалению.
У меня тут есть статьи, почему у меня не взлетело с порталом недвижимости. Сейчас на домене стоит заглушка другого проекта по ЖК, который я не стал развивать, так как меня забрали на другой крупнейший проект по недвижимости (благодаря и этому опыту). Но зато взлетело другое (маркетплейс направления). А как у вас дела, у диванного эксперта? За 20 лет у меня десятки проектов доведенных до релиза и вагон опыта, который я смог монетизировать на других проектах. А что у вас? С удовольствием послушаю ваши истории успеха, очень хочу приобщиться к вашей мудрости.
Ну, во-первых, я не работодатель. Работодатель — это аутсорсинговая компания и заказчик, который оплачивает весь этот «праздник жизни». А во-вторых — я всего-навсего описал рабочий процесс, который никому не навязываю. Я могу снять людей с проекта, но уволить я их не могу.
Ну и последний момент: «Нет такой профессии, как хороший парень». Если сотруднику что-то не нравится, то он вправе найти более подходящее место работы. Тут уже вопрос в том, что такие люди не будут получать высоких зарплат. А тот, кто хочет иметь высокий доход, тот будет идти в ногу с заказчиком, ради заказчика, и для заказчика и соответственно, проекта. По другому не бывает.
Мне кажется, что вы очень сильно переоцениваете ситуацию на рынке труда. Наниматели из Европы и США мониторят весь мир, а не только страны бывшего Советского Союза. И наших программистов нанимают не потому, что они такие гениальные, а потому что они дешевые. И нанимают в основном гребцов, так как у них есть свой менеджмент и лиды.
Отвечая на ваш вопрос, то такого спеца просто выгонят на мороз. А при устройстве в следующую контору, если у него мозгов хватает, то он будет говорить, что сам ушел, так как вырос. А если начнет понисить старое место работы, то и новое не найдет, так как токсичные и неадекватные люди никому не нужны.
А если, вдруг, какой-то компании позарез нужен будет высококвалифицированный специалист здесь и сейчас, то искать на улице никто не будет. Его схантят с другой работы с зарплатой + 1 тыс. долларов, вот и всех делов-то.
Тогда почему в данном конкретном случае кто-то ушёл когда «поменялись правила»? :)
Потому что многие люди не хотят/не могут выходить из зоны своего комфорта. Но это не проблемы бизнеса, а этих людей. Для того, чтобы что-то найти (деньги, людей, процессы, и т.д.), то нужно это искать. А тот, кому хорошо и так, без этой вечной суеты, остаются за бортом возможностей. Люди ушли из проекта. Кто-то на бенч, кто-то в другие проекты. Кого-то потом уволили, после пары негативных отзывов от другого заказчика (вообще очень частый случай). На аутсорсе «отсидеться» не получится — это я гарантирую на 100%.
Спасибо за ответ, попробую все прояснить более детально:
Максимально описана, это как? Как по мне, в идеале это прямо код или в крайнем слечае псевдокод. Но я сильно подозреваю, что зачастую в описании используются подразумеваемые особенности (но которые в коде все равно отражаются), типа если добавляем кнопку, то не указываем, что вид у нее стандартный для проекта и подобное.
Например, есть задача: отправку напоминанию клиенту, что нужно оплатить инвойс. Обычная постановка задачи так и звучит, что нужно сделать такую фичу. И тут возникает ряд вопросов. А отправлять напоминание нужно один раз или много? Если много, то с каким промежутком? А напоминать через мыло или еще и через СМС, вебсокеты и т.д.? А если клиент так и не заплатил, то что делать с этим, до конца дней присылать уведомления? А если нужно останоить рассылку, то при каких условиях? Без ответов на эти вопросы не возможно четко выполнить поставленную задачу. Вот поэтому и нужно подробно описать заказчику, что нужно делать. Если он этого не может сделать или толково объяснить, то я созваниваюсь с заказчиком и мы все это обсуждаем. Я создаю флоу и кидаю на утверждение.
А какая фича сложная? По времени реализации, по числу задействованных людей, по необходимым усилиям что бы эту фичу вообще придумать как делать? Ну и, естественно, отсюда вытекает невозможность адекватно поделить ее на мелкие.
Любая фича сложная, которая не может быть самостоятельно закрыта одним разработчиком в относительно короткие сроки. Системы рассылки, система заказов, платежная система и т.д. — это все сложные фичи. По факту это даже не сторисы а эпики.
Здесь отобразить кнопку сохранения данных, тут выводить какое-то агрегации и т.д. — это простые фичи, которые можно сразу осознать и понять, как их сделать. При этом потратив на них минимум времени.
Еще не указана численность и состав команды, а это очень важно, что-то будет хорошо работать в малом коллективе, что-то в большом. Кроме того, нужно было сразу и отдельно указать особенности взаимодействия с заказчиком. К примеру, я не понял, есть ли вообще выделенные тестеры в команде? Или может они есть у заказчика? Непонятно.
Изначально на проекте было 8 человек. 1 ПМ/аналитик, 1 QA 4 бэкендера и 2 фронтендера. В итоге сроки посрочены, работа топталась на месте, все искали виновных, проект замер. Клиент стал зверствовать и почти всех поувольнял. В итоге, осталось всего 3 человека. Я (пишу и бэк и фронт, выполняю роль и системного аналитика и архитектора, скрам тоже на мне), один бэкендер сениор и один фронтендер сениор. Перформанс увеличился раз в 10! Клиент теперь спокоен, как удав. Затраты уменьшились в разы, скорость увеличилась на порядок.
Так кто назначает задачи? Каждый сам планирует что делать? Может раздает тимлид? А вообще есть ли в этом смысл, если нужно брать следующую по приоритету? В общем пункты друг другу немного противоречат.
Все бизнес задачи создает заказчик. Но прилетают они все на меня. Я все их просматриваю и назначаю на людей. Каждую новую задачу мы обсуджаем на митинге. Я тоже создаю задачи, когда вижу в этом необходимость (изменение бизнес логики, рефакторинг, фикс багов, которые я нашел и т.д.).
Если все трекается, то какой смысл говорить о том, что сделано и делается? Кому интересно, может открыть жиру и посмотреть, кому не интересно, тот мимо ушей пропустит (вот я, к примеру, всегда так делаю :) ) Ну и зачем разрабу отписывать в чате чего сделано? Бота нельзя настроить, если уж заказчик по каким-то причинам не может пользоваться жирой?
Жира — это всего-лишь инструмент с кучей флагов. На каждом митинге мы всегда в курсе всего процесса работы. Фронтендер четко знает, что творится на бэке. Бекендер все знает о фронте. Так как на фронте юзается Реакт, то сам фронтендер в отрыве от бэкенда ничего не сможет сделать и наоборот. Создание одной конкреной фичи — это когда и бэк и фронт синхронно работают над одной задачей, чтобы превратить это в законченный кусок функционала. А так как мы еще юзаем кучу «хайповых» технологий и с десяток дополнительных АПИ сервисов, то не знание всего проекта целиком для кого-либо на проекте подобно смерти.
Что касается отпусков, то уже все, и я в том числе, уходили в отпуска не раз. Здесь вообще нет никакой проблемы. Все об отпусках договариваются одновременно. Мы составляем план релиза с учетов этого обстоятельства.
А по факту самого процесса программирования, то мы тратим процентов 70 нашего времени именно на дискуссии, обсуждение бизнес логики, архитектуру и планирование. И только 30% на сам кодинг. В итоге мы успеваем все, так как ничего не приходиться по десять раз переделывать.
Все что написано в статье — это не догма! А всего-навсего частный случай в моей команде. И людей я подбирал именно тех, которые все это могут. Оплата труда вполне сответствующая. Никого выгонять не нужно. В аутсорсинговых компаниях ведется много параллельных проектов. Люди могут мигрировать с проекта в проект. А еще есть оплачиваемый бенч.
Есть амбициозные программисты с хорошими скилами и им очень тесно с простыми гребцами в одной лодке. Но проекты, на которых они работают, не могут предложить им большего. Мой проект может. В любом случае, при таком подходе, люди с моего (вернее проекта компании) проекта становятся более подготовленными и желанными для заказчика.
Что касается про прием на работу на одних условиях, а потом смена на другие условия. Такого понятия вообще нет. Проект от проекта могут очень сильно отличаться. Помимо собеседования в компанию, нужно еще постараться пройти собеседование с заказчиком, так как именно он платит деньги и хочет знать, с кем ему придется работать.
Главное условия для соискателя — это набор определенных профессиональных и личностных качеств в обмен на достойную зарплату и бонусный пакет. Поэтому все может меняться очень сильно в течении года.
Профессиональных программистов в отрыве от бизнеса не существует. Сами по себе они ни кому не нужны. Именно по этому балом правит бизнес, которому и нужно создать решение. А если учесть, что это высоко конкурентная сфера, то заявлять заказчику, что он тебе не интересен и ты не будешь работать так, как это нужно для проекта, означает остаться за бортом и плавать в маленьких шлюбках третестепенных контор.
На аутсорсе это частое явление. Заказчики, в основном, не хотят оплачивать наемный менеджмент со стороны подрядчика (ПМ, аналитики и т.д.). Им нужны только технари, а менеджмент они сами предоставляют. Порой это не самые квалифицированные специалисты, именно в областе ИТ, но они хорошо разбираются в бизнес вопросах и в том, что именно им нужно. Поэтому, когда в такой проект кидают только программистов без опыта управления и общения напрямую с заказчикамы, то проекты, как правило, проваливаются. И это, к сожалению, объективная реальность. Именно поэтому, многие компании требуют знание английского на хорошем уровне и наличие развитых софт скилов. Но это уже другая история ))
Мы используем систему управления проектами Atlassian Jira. Все задачи вместе со статусами ведуться в этой системе. В ней же и настроено флоу для работы. Клиент создает в ней задачи и контролирует их там.
Это касается сугубо моего проекта и видения. До этого каждый сам себе что-то «понимал» из задачи в два абзаца и пилил совсем не то, что было нужно заказчику. Прожект менеджера на проекте нет (с нашей стороны), в качестве него выступает член комады со стороны заказчика. Прокт европейский, все только на английском, естественно. Процент недопонимания друг друга немаленький.
UI/UX дизайн правильная и нужная вещь. Но есть достаточно большое количество сайтов, где вообще нет никакого дизайна, но ресурс востребован. И наоборот, есть супер дизайн по всем канонам UI/UX, а проект не востребован. И тут вопрос, а в дизайне ли дело. И если и в нем тоже, то сколько процентов он имеет в финальном результате от всего проекта?
Согласен. Я долго думал, включать ли MVP в статью или нет. Но я подумал о том, что если проект является каким-то замороченным SaaS сервисом или маркетплейсом, то для него нужно все равно создать набор каких-то фич. А это потянет на себя и время и бюджет. Как тогда создать минимально жизнеспособный проект в таком случае, я не придумал, к сожалению.
Очень интересен вопрос расчета бюджета. Я обратил внимание, что подавляющее большинство стартапов планирует бюджет в основном только на сам процесс разработки. Часто даже жмут на профессиональное тестирование, сами хотят все тестировать. И это я не про наших даже говорю, а про западные компании (США, Германия, Нидерланды и т.д.). А вот что делать дальше с созданным продуктом, некоторые толком и не понимают. Была цель создать маркетплейс, его создали. А как привлечь на него пользователей, тут уже совсем другой вопрос и деньги.
Я с вами полностью согласен, что маркетплейсы — это очень сложная штука. Я работаю в компании Syndicode и только при мне было сделано 5 разноплановых маркетплейсов, из которых смогли раскрутится только два (Германия и Нидерланды). А три так и не смогли подняться. И главная причина успеха двух успешных проектов была именно в том, что они строили электронные торговые площадки на базе уже своего существующего и успешного бизнеса. Это позволило им вылезти из уже «тесных штанишек». А вот те, которые не смогли взлететь, были как раз чистого вида стартапами, которые начинались на базе голой идеи. Я попробую более подробно рассказать в следующих статьях. Но не смотря на сложность создания маркетплейсов, все равно будут находится желающие попробовать свои силы в этом виде бизнеса. По сути проблемы у всех одинаковые, а вот путь к успеху у всех разный. И повторить его довольно сложно.
Все зависит от того, что вы за программист. Простому кодеру формошлеперу, нет смысла. Инженеру, который очень четко хочет понимать бизнес требования из первых уст, есть смысл.
Для начала, не мешало бы примерить эту же рубашечку на себя. А то получается, что кругом одни дебилы, а вы такой, на белом коне. Интересно было бы услышать мнение о вас от этих, упомянутых вами, сотрудников. Было бы безумно любопытно.
А вообще, работать с людьмы - это не каждому дано. Это намного сложнее, чем код писать, или строчить статейки о своей некомпетентности. А именно так я ее и восспринимаю, к сожалению.
Привет. Да, все оказалось сложнее, чем казалось. Я написал об этом пару статей: https://habr.com/ru/post/438252/
Ну и последний момент: «Нет такой профессии, как хороший парень». Если сотруднику что-то не нравится, то он вправе найти более подходящее место работы. Тут уже вопрос в том, что такие люди не будут получать высоких зарплат. А тот, кто хочет иметь высокий доход, тот будет идти в ногу с заказчиком, ради заказчика, и для заказчика и соответственно, проекта. По другому не бывает.
Отвечая на ваш вопрос, то такого спеца просто выгонят на мороз. А при устройстве в следующую контору, если у него мозгов хватает, то он будет говорить, что сам ушел, так как вырос. А если начнет понисить старое место работы, то и новое не найдет, так как токсичные и неадекватные люди никому не нужны.
А если, вдруг, какой-то компании позарез нужен будет высококвалифицированный специалист здесь и сейчас, то искать на улице никто не будет. Его схантят с другой работы с зарплатой + 1 тыс. долларов, вот и всех делов-то.
Потому что многие люди не хотят/не могут выходить из зоны своего комфорта. Но это не проблемы бизнеса, а этих людей. Для того, чтобы что-то найти (деньги, людей, процессы, и т.д.), то нужно это искать. А тот, кому хорошо и так, без этой вечной суеты, остаются за бортом возможностей. Люди ушли из проекта. Кто-то на бенч, кто-то в другие проекты. Кого-то потом уволили, после пары негативных отзывов от другого заказчика (вообще очень частый случай). На аутсорсе «отсидеться» не получится — это я гарантирую на 100%.
Например, есть задача: отправку напоминанию клиенту, что нужно оплатить инвойс. Обычная постановка задачи так и звучит, что нужно сделать такую фичу. И тут возникает ряд вопросов. А отправлять напоминание нужно один раз или много? Если много, то с каким промежутком? А напоминать через мыло или еще и через СМС, вебсокеты и т.д.? А если клиент так и не заплатил, то что делать с этим, до конца дней присылать уведомления? А если нужно останоить рассылку, то при каких условиях? Без ответов на эти вопросы не возможно четко выполнить поставленную задачу. Вот поэтому и нужно подробно описать заказчику, что нужно делать. Если он этого не может сделать или толково объяснить, то я созваниваюсь с заказчиком и мы все это обсуждаем. Я создаю флоу и кидаю на утверждение.
Любая фича сложная, которая не может быть самостоятельно закрыта одним разработчиком в относительно короткие сроки. Системы рассылки, система заказов, платежная система и т.д. — это все сложные фичи. По факту это даже не сторисы а эпики.
Здесь отобразить кнопку сохранения данных, тут выводить какое-то агрегации и т.д. — это простые фичи, которые можно сразу осознать и понять, как их сделать. При этом потратив на них минимум времени.
Изначально на проекте было 8 человек. 1 ПМ/аналитик, 1 QA 4 бэкендера и 2 фронтендера. В итоге сроки посрочены, работа топталась на месте, все искали виновных, проект замер. Клиент стал зверствовать и почти всех поувольнял. В итоге, осталось всего 3 человека. Я (пишу и бэк и фронт, выполняю роль и системного аналитика и архитектора, скрам тоже на мне), один бэкендер сениор и один фронтендер сениор. Перформанс увеличился раз в 10! Клиент теперь спокоен, как удав. Затраты уменьшились в разы, скорость увеличилась на порядок.
Все бизнес задачи создает заказчик. Но прилетают они все на меня. Я все их просматриваю и назначаю на людей. Каждую новую задачу мы обсуджаем на митинге. Я тоже создаю задачи, когда вижу в этом необходимость (изменение бизнес логики, рефакторинг, фикс багов, которые я нашел и т.д.).
Жира — это всего-лишь инструмент с кучей флагов. На каждом митинге мы всегда в курсе всего процесса работы. Фронтендер четко знает, что творится на бэке. Бекендер все знает о фронте. Так как на фронте юзается Реакт, то сам фронтендер в отрыве от бэкенда ничего не сможет сделать и наоборот. Создание одной конкреной фичи — это когда и бэк и фронт синхронно работают над одной задачей, чтобы превратить это в законченный кусок функционала. А так как мы еще юзаем кучу «хайповых» технологий и с десяток дополнительных АПИ сервисов, то не знание всего проекта целиком для кого-либо на проекте подобно смерти.
Что касается отпусков, то уже все, и я в том числе, уходили в отпуска не раз. Здесь вообще нет никакой проблемы. Все об отпусках договариваются одновременно. Мы составляем план релиза с учетов этого обстоятельства.
А по факту самого процесса программирования, то мы тратим процентов 70 нашего времени именно на дискуссии, обсуждение бизнес логики, архитектуру и планирование. И только 30% на сам кодинг. В итоге мы успеваем все, так как ничего не приходиться по десять раз переделывать.
Есть амбициозные программисты с хорошими скилами и им очень тесно с простыми гребцами в одной лодке. Но проекты, на которых они работают, не могут предложить им большего. Мой проект может. В любом случае, при таком подходе, люди с моего (вернее проекта компании) проекта становятся более подготовленными и желанными для заказчика.
Что касается про прием на работу на одних условиях, а потом смена на другие условия. Такого понятия вообще нет. Проект от проекта могут очень сильно отличаться. Помимо собеседования в компанию, нужно еще постараться пройти собеседование с заказчиком, так как именно он платит деньги и хочет знать, с кем ему придется работать.
Главное условия для соискателя — это набор определенных профессиональных и личностных качеств в обмен на достойную зарплату и бонусный пакет. Поэтому все может меняться очень сильно в течении года.
Профессиональных программистов в отрыве от бизнеса не существует. Сами по себе они ни кому не нужны. Именно по этому балом правит бизнес, которому и нужно создать решение. А если учесть, что это высоко конкурентная сфера, то заявлять заказчику, что он тебе не интересен и ты не будешь работать так, как это нужно для проекта, означает остаться за бортом и плавать в маленьких шлюбках третестепенных контор.
Это все ИМХО.
www.senden24.com/how_it_work
Здесь команда, кто разрабатывал:
www.senden24.com/team