Обещанное о далеких островах (: попробую резюмировать кратко впечатления от работы наших удаленных коллег - работы на границе двух больших систем. Оно все, конечно, очевидно, но может кому пригодится...
Самые очевидные вещи порой скипаются надеждой на то, что они очевидны всем, а сталбыть, таких ошибок люди не должны совершать в работе. Ну потому что обычно никто не хватается руками за подошву горячего утюга - будут же очевидно здоровенные волдыри. Удивительно, но есть люди, щупающие горячий утюг много раз подряд. Мазо?
Читать далее1. Для успешного завершения проекта вам нужны исполнители хотя бы среднего уровня профессионализма и самодисциплины. Дисциплинированные новички, а также очень опытные и технически грамотные раздолбаи могут не вытянуть. Люди должны хотя бы уметь читать. Хотя бы то, что им пишут технические консультанты со стороны системы, с которой надо интегрироваться. И люди должны быть способными учитывать прочтенное. Не только двести пятьдесят с четвертью раз повторенное, но и раз сказанное.
2. Если вам дали в помощь технического консультанта фактически на фултайм, то надо этим как-то пользоваться. Разумно надо этим пользоваться как-то. В частности, если на старте сэйлс менеджер со стороны системы, с которой вы интегрируетесь, дал вам пакет документации, определяющей всю вашу дальшейшую работу по проекту, а после этого технический консультант вам выслал аналогичный пакет документации, то какой из двух пакетов надо использовать? И надо ли вообще заглядывать во второй пакет? И какими словами надо ругаться на языке солнечного островгого государства, когда через 2 месяца трудов выяснится, что вы все это время девелопали что-то не то?
3. Хорошо бы приоритезировать весь заказанный функционал, и реализовывать по-возможности в порядке приоритета. А когда вы не успеваете реализовать все запланированное, и у вас над душой стоит клиент, которому светит из-за этого пропустить крисмас, не стоит бросаться делать все самое ненужное. Агрументы, что это пригодиттся будущим клиентам, текущего клиента не утешат. Тем более, что после того, как этот клиент пропустит крисмас, других клиентов может уже и не быть.
4. Если вам надо разработать некий общий функционал, и несколько его слегка урезанных вариантов, то не надо поручать каждый из них разным людям. Если вы сделали, потестили, отладили, очистили от мусора, вылизали и обклеили стразами это самое общее, то почему бы не сделать частное мелкой подстрижкой общего? Какой смысл отдельно с нуля делать частное, наступая второй, третий и все последующие разы на одни и те же грабли? И не тыкать при этом пальцами в синяки одного исполнителя, дабы предостеречь другого?
5. Крепко задумайтесь, действительно ли ваша команда так никудышна, чтобы менять ее прямо накануне релиза. Потом сделайте получасовой перекур и еще раз крепко задумайтесь. Если вы объявите команде, что после релиза их разгонят, то мало шансов, что они кинутся с утроенным энтузиазмом фигачить на благо проекта. Они скорее будут вяло отпинываться в сторону команды, которая должна будет подхватить проект после них. А новая команда будет еще не в контексте. И ваш тщательно запланированный канун релиза может затянуться до крисмаса, такого желанного для несчастного клиента.
6. Гостиничный бизнес, или ловля креветок? Ловля креветок, или гостиничный бизнес?