Antifragility in IT. How to achieve results in IT projects under conditions of uncertainty
I read Alexander Byndyu’s book in a couple of days and I had very mixed feelings about the book.
First I will run through the pluses and disassembled themes. At the beginning of the book, a lot of time is devoted to useful product practices: impact mapping. (I already am. described book of the same name), customer journey map, user story mapping
- Well disassembled problems with a large and formal technical task (TB) Talks about working with requirements in agile projects Reasons for failure of IT projects are well discussed Project management models: fixed price, time and materials and partly fff (fix time, fix budget, flex scope) The second part gives a helicopter view on how to build development processes in a custom development model A story about monoliths, microservice monoliths, microservices and further orchestrators of business services is given. Where to use low-code platdoms and when it is time to get off them How to work with legacy systems and how to start projects to transition from them What to do with technical debt
Now a little about the minuses. The title of the book is a reference to the work of Nasim Taleb, who, in my opinion, is a graphomaniac, the meaning of whose works is usually easily fit into one page. The book tells about the interaction of customers / performers in the model of custom development, other models are not considered The concepts of project and product are mixed and used interchangeably, which, from the point of view of the executing company, is understandable in the custom development model, but not so in the product company. (You can read more in my article "About project management and products")
Sometimes I'll write "project" and sometimes "product." For myself, I do not share these two concepts. (1 part, chapter 4) Part of the chapters looks like working out the objections of the customer when selling the project to him - an example of working on TK or selling FFF (fix time, fix budget, flex scope) A concept that, to me, looks just like another term for time & materials:) Most of the graphs in the book are given simply to illustrate the thoughts of the author - behind these graphs there are no numbers and some statistics, pure illustration. In general, there are no traces of a scientific approach in the book - the argumentation is based on examples from Alexander's consulting practice and alternative points of view are not given. In the part about IT, everything is written so briefly and thematically that if you do not know all the sources that Alexander refers to, then you can only believe the word. Microservices are sold as a response to a change adaptability request, and then more and more like a story about how to start a project to transition from a monolith to a new solution and what technical problems should be included in the contract to avoid screwing up.
- Many times there is a refrain about the fact that you need to call an IT consultant on time for a technical audit ... and not only that.
In general, I would call the book “How to order / sell IT projects” and would note that the book can be very useful for two categories. n Business customers who need to complete an IT project and want to understand how to do it and not screw up Executors who sell their services and perform projects, but do not want to sell their hands on time & materials due to low margins, and are also afraid of risks in the fix price scheme:) The rest recommend paying more attention to the materials to which the author refers and which by the end of the book ran over. 100 byndyu.ru/footnote/{id} (from 1 before 100)
#Management #Software #Architecture #Processes #Project #ProductManagement #Engineering #Processes #Consulting