Однажды мне пришлось участвовать в очень интересном проекте для крупной логистической компании с несколькими складами. Не буду вдаваться в подробности, но перед компанией встала проблема оптимизации распределения хранимых продуктов. Нужно было решить задачу так, чтобы на разгрузку и погрузку уходило минимальное количество времени. Проект имел огромный успех. Компания наконец-то выполнила 10% предполагаемого плана продаж.
Вот только ни о каком успехе не может быть и речи. Компания так и не выполнила план продаж!
Противоречия на самом деле нет. Проект имел огромный успех, потому что заказчик остался очень доволен конечным результатом. Другое дело, что прибыль он так и не получил.
В этой статье я собираюсь немного «покопаться» в классическом понимании того, как работает софтверная компания. Однако постарайтесь дойти до конца, и вы обнаружите, что такой подход может показаться интересным.
Успех проекта не следует рассчитывать исключительно в пересчете на прибыль. Не поймите меня неправильно, я знаю, что без денег ни один бизнес не продержится долго. Однако я считаю, что деньги – это результат хорошо выполненной работы. Что же в таком случае можно считать успехом проекта и какой секрет программирования с ним связан?
Однако, несмотря на огромный скачок, который нам позволило сделать программное обеспечение, оно так и остается только инструментом, предназначенным для решения различных проблем.
Хорошо выполненная работа – это решение проблемы клиента. В конце концов, это причина, по которой вы сидите за клавиатурой и составляете приложение из последовательных строк! Это не вы, а кто-то, заплативший за вашу работу, решил, что заработает больше, если потратит деньги на решение (программное обеспечение), решающее его проблему (или проблему его клиентов).
Однако возникает вопрос, что нужно построить с клиентом? Программное обеспечение или отношения?
Программное обеспечение не всегда является ответом на потребности бизнеса. Выстраивая долгосрочное сотрудничество, мы получаем выгоду от решения проблем, а не от добавления еще одного приложения в портфолио компании.
Точное и относительно быстрое решение проблемы стало возможным благодаря очень высокой вовлеченности клиента в проект. Он участвовал на каждом этапе его создания, постоянно давая полезные советы и ценные отзывы. Он был точнейшим тестером и подавлял любые тенденции разработчиков отойти от четкого задания, которые не приводили к желаемому результату.
Однако если нам есть что взять из этого популярного сейчас подхода, так это тесное сотрудничество с клиентом и то, что для успешной работы в дальнейшем такой путь неизбежен.
Еще одна неприятная для клиента особенность отечественных (и не только их) программистов – стремление использовать наработки кода, адаптируя его под нужды заказчика. Если рассматривать решение задачи как самую важную цель, оказывается, что оно может иметь прямое влияние на программирование.
Каждая написанная строчка кода должна давать пользователю возможность упростить его работу с минимальным участием с его стороны. Какие у этого принципы?
Если мы работаем над решением проблемы – неважно, сколько часов в день программист сидел за клавиатурой, и уж точно не имеет значения объем написанного кода.
Единственное, что имеет значение, – предоставит ли программист полноценное решение в срок, согласованный с менеджером проекта.
Что касается количества написанных строк кода, хотя звучит несколько абсурдно, но правда в том, что лучшая «программа» – это та, в которой нет ни одной строки кода. Если проблема решена с минимальными усилиями... это плюс!
Лучше считать получившиеся решения задач, а не часы работы.
Во многих компаниях время, проведенное перед экраном монитора, по-прежнему считается высшим достоинством. Однако есть также много мест, где конечное решение важнее.
Когда мы пишем код, давайте помнить, как можно максимально сократить путь пользователя к желаемому результату. Компания, на которую мы работаем, и компания клиента только выиграют от этого.
Почти наверняка никаких секретов я не открыл, но, как ни странно, многие софтверные компании по-прежнему предпочитают ориентироваться не на клиента, а убеждать его в гениальности своих творений.
Желаете вы прокачать навыки программирования, тестирования или управления проектами — это можно сделать онлайн на образовательной платформе в удобном для вас формате.
habr.com
Вот только ни о каком успехе не может быть и речи. Компания так и не выполнила план продаж!
Противоречия на самом деле нет. Проект имел огромный успех, потому что заказчик остался очень доволен конечным результатом. Другое дело, что прибыль он так и не получил.
В этой статье я собираюсь немного «покопаться» в классическом понимании того, как работает софтверная компания. Однако постарайтесь дойти до конца, и вы обнаружите, что такой подход может показаться интересным.
Успех проекта не следует рассчитывать исключительно в пересчете на прибыль. Не поймите меня неправильно, я знаю, что без денег ни один бизнес не продержится долго. Однако я считаю, что деньги – это результат хорошо выполненной работы. Что же в таком случае можно считать успехом проекта и какой секрет программирования с ним связан?
Дело не в написании кода, а в ...
Программное обеспечение – это всего лишь инструмент. Очень мощный, который за несколько лет буквально изменил мир до неузнаваемости. Не так давно, 20 лет назад, никто даже не представлял, насколько комфортной может стать жизнь благодаря строчкам кода, исполняемым компьютером.Однако, несмотря на огромный скачок, который нам позволило сделать программное обеспечение, оно так и остается только инструментом, предназначенным для решения различных проблем.
Хорошо выполненная работа – это решение проблемы клиента. В конце концов, это причина, по которой вы сидите за клавиатурой и составляете приложение из последовательных строк! Это не вы, а кто-то, заплативший за вашу работу, решил, что заработает больше, если потратит деньги на решение (программное обеспечение), решающее его проблему (или проблему его клиентов).
Однако возникает вопрос, что нужно построить с клиентом? Программное обеспечение или отношения?
Программное обеспечение не всегда является ответом на потребности бизнеса. Выстраивая долгосрочное сотрудничество, мы получаем выгоду от решения проблем, а не от добавления еще одного приложения в портфолио компании.
Решение проблем как основная цель
Вернемся к проекту в начале статьи. Он завершился успехом, потому что за 3 месяца нам удалось решить проблему в логистической компании, используя достаточно простое, малофункциональное и легко портируемое (включая необходимое оборудование) решение.Точное и относительно быстрое решение проблемы стало возможным благодаря очень высокой вовлеченности клиента в проект. Он участвовал на каждом этапе его создания, постоянно давая полезные советы и ценные отзывы. Он был точнейшим тестером и подавлял любые тенденции разработчиков отойти от четкого задания, которые не приводили к желаемому результату.
Однако если нам есть что взять из этого популярного сейчас подхода, так это тесное сотрудничество с клиентом и то, что для успешной работы в дальнейшем такой путь неизбежен.
Сократите путь к результату, как это связано с программированием
Многие программисты очень не любят вплотную работать с заказчиком. Это тяжело, так как постоянно приходится вносить коррективы в продукт. Большинство предпочитают выполнить задачу без консультаций с клиентом, лишь уточнив ее пере6д работой. Затем согласование и, возможно, доработка происходит перед сдачей программного обеспечения. Вот только не факт, что клиент обратится в вам снова. А главная задача с точки зрения выстраивания отношений – именно эта.Еще одна неприятная для клиента особенность отечественных (и не только их) программистов – стремление использовать наработки кода, адаптируя его под нужды заказчика. Если рассматривать решение задачи как самую важную цель, оказывается, что оно может иметь прямое влияние на программирование.
Каждая написанная строчка кода должна давать пользователю возможность упростить его работу с минимальным участием с его стороны. Какие у этого принципы?
- проектируются и создаются функциональные возможности -> не модули;
- функция выполняет именно то, что должна -> код заранее не готовится;
- внимание фокусируется на главной проблеме, которую необходимо решить -> не открываем заново Америку;
- всегда можно сделать меньше (проще, лучше), а творчество начинается с ограниченными ресурсами -> мы не перетаскиваем проект и не добавляем ресурсы.
Измеряйте продуктивность сотрудников
Все это поднимает серьезный вопрос: следует ли измерять ИТ в часах или строках кода по отношению ко всему вышеперечисленному?Если мы работаем над решением проблемы – неважно, сколько часов в день программист сидел за клавиатурой, и уж точно не имеет значения объем написанного кода.
Единственное, что имеет значение, – предоставит ли программист полноценное решение в срок, согласованный с менеджером проекта.
Что касается количества написанных строк кода, хотя звучит несколько абсурдно, но правда в том, что лучшая «программа» – это та, в которой нет ни одной строки кода. Если проблема решена с минимальными усилиями... это плюс!
Лучше считать получившиеся решения задач, а не часы работы.
Во многих компаниях время, проведенное перед экраном монитора, по-прежнему считается высшим достоинством. Однако есть также много мест, где конечное решение важнее.
Заключение
Думаю, всем разработчикам пора перестать смотреть на своих клиентов как на не очень умных конечных пользователей их великих творений. Надо встать «на их место» и подумать о проблеме заказчика, а затем решить ее.Когда мы пишем код, давайте помнить, как можно максимально сократить путь пользователя к желаемому результату. Компания, на которую мы работаем, и компания клиента только выиграют от этого.
Почти наверняка никаких секретов я не открыл, но, как ни странно, многие софтверные компании по-прежнему предпочитают ориентироваться не на клиента, а убеждать его в гениальности своих творений.
Желаете вы прокачать навыки программирования, тестирования или управления проектами — это можно сделать онлайн на образовательной платформе в удобном для вас формате.
Принцип программирования, про который часто забывают
Однажды мне пришлось участвовать в очень интересном проекте для крупной логистической компании с несколькими складами. Не буду вдаваться в подробности, но перед компанией встала проблема оптимизации...
habr.com